Hi Jörn, Sage,
Al has now created a "write_inode" branch in the vfs tree that just
contains the changes that your trees need to be fixed up for. Al
promises that this branch will never be rebased. So the best solution is
for you both to merge that branch into your respective trees ("git pull
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6.git
write_inode") and then apply the patches I sent (assuming that they are
correct). If you rebase your trees, you will need to repull the above
branch, of course.
[Alternatively, you could create a remote in your trees for Al's
write_inode branch:
git remote add -f -t write_inode write_inode git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6.git
and then merge it using
git merge write_inode
That way if anything is added to that branch you can just refetch it and
merge it again if necessary.]
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On Mon, 18 Jan 2010, Stephen Rothwell wrote:
> Hi J?rn, Sage,
>
> Al has now created a "write_inode" branch in the vfs tree that just
> contains the changes that your trees need to be fixed up for. Al
> promises that this branch will never be rebased. So the best solution is
> for you both to merge that branch into your respective trees ("git pull
> git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6.git
> write_inode") and then apply the patches I sent (assuming that they are
> correct). If you rebase your trees, you will need to repull the above
> branch, of course.
That works, thanks. I was planning on just making sure my tree got pulled
after the vfs tree, but this will work either way.
More generally, I'm not sure I understand how your fixups are supposed to
be used down the line. Is whichever tree that caused the conflict to get
merged second supposed to pick it up in their branch to pull, or are those
patches being fed to Linus somehow, or does he usually fix up those
conflicts himself?
Thanks-
sage
Hi Sage,
On Mon, 18 Jan 2010 15:16:39 -0800 (PST) Sage Weil <[email protected]> wrote:
>
> That works, thanks. I was planning on just making sure my tree got pulled
> after the vfs tree, but this will work either way.
It looks like you added my patch to your tree, but did not merge Al's
write_inode branch. So, I assume that your tree is currently broken if
built on its own.
> More generally, I'm not sure I understand how your fixups are supposed to
> be used down the line. Is whichever tree that caused the conflict to get
> merged second supposed to pick it up in their branch to pull, or are those
> patches being fed to Linus somehow, or does he usually fix up those
> conflicts himself?
Yeah, either the second tree's owner will do the fixup after the first is
merged into Linus' tree or (more commonly for simple fixups), Linus will
do the fix when he merges the second tree. In this particular case, the
conflicts are not noticed by git during the merge, so they need to be
done manually by the second tree's owner, or by Linus (if we tell him).
I will attempt to remember to warn Linus if these conflicts remain during
the next merge window but if you and Jörn merge Al's branch and apply the
fix, then it will all be OK.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
Hi Stephen,
On Tue, 19 Jan 2010, Stephen Rothwell wrote:
> It looks like you added my patch to your tree, but did not merge Al's
> write_inode branch. So, I assume that your tree is currently broken if
> built on its own.
Not to worry, only the for-next branch.
> > More generally, I'm not sure I understand how your fixups are supposed to
> > be used down the line. Is whichever tree that caused the conflict to get
> > merged second supposed to pick it up in their branch to pull, or are those
> > patches being fed to Linus somehow, or does he usually fix up those
> > conflicts himself?
>
> Yeah, either the second tree's owner will do the fixup after the first is
> merged into Linus' tree or (more commonly for simple fixups), Linus will
> do the fix when he merges the second tree. In this particular case, the
> conflicts are not noticed by git during the merge, so they need to be
> done manually by the second tree's owner, or by Linus (if we tell him).
>
> I will attempt to remember to warn Linus if these conflicts remain during
> the next merge window but if you and J?rn merge Al's branch and apply the
> fix, then it will all be OK.
Okay, that makes sense. I've merged Al's branch, so feel free to forget. :)
Also, I resolved the ioctl-number.txt fixup you're carrying in that merge,
so you should be able to drop that. I'll make sure both conflicts are
dealt with in my tree one way or another before it gets pulled.
Thanks!
sage