From: Harald Welte <[EMAIL PROTECTED]>
Date: Thu, 11 Aug 2005 18:44:30 +0200
> On Tue, Aug 09, 2005 at 06:23:33PM -0700, David S. Miller wrote:
> > I want some net bug fixes in Linus's tree to propagate into the
> > net-2.6.14 tree so I plan to rebase it this evening, so please be
> > careful when sync'ing with my tree over the next day.
>
> so what is the actual process of a 'rebase' on your side? Do you just
> pull/update from Linus' current tree and merge it with yours? Or do you
> extract all the patches and apply them to a clean linus-tree?
>
> And what is the designated course of action for somebody (like me), who
> has based his tree on yours? I just do 'cg-update origin' and manually
> go through the changes, clean them up. Finally I chekc with 'cg-diff -r
> origin' whether there were any mistakes during the manual
> cleanup/conflict resolving by making sure it only contains the desired
> netfilter-related changes.
>
> Is that the "best current practise", or would you recomment a different
> course of action?
What I do is I extract all of the patches out of the net-2.6.14
tree, then apply them one-by-one into a fresh copy of Linus's tree,
then replace the tree on kernel.org with the new one.
I even go one step further and combine some patches that logically
belong together, for example build fixes from Andrew Morton I'll
combine with the patch that added the build regression. This is
becomming more and more necessary now that we have more than 110
patches in net-2.6.14
I would suggest folks don't try to do any merging with this tree
when I do that. None of the old tree remains in any form whatsoever
in the new tree, so there isn't anything to merge with.
You need to pull out your patches from the old tree, and add them to
the new tree.
I know this is a pain in the butt, but I absolutely do not want ugly
merge-mania type history graphs in the net-2.6.14 tree just because
I felt like rebasing. And the net-2.6.14 tree touches so many things
that merges wouldn't be that successful anyways :-)
If you keep your .git/ORIG_HEAD sane, you can use a script like the
following to pull your local changes out of a tree one-by-one. It
drops them into a directory called "patches/" at the top-level and
names them 1.diff, 2.diff, 3.diff, etc. with changelogs prepended
to the beginning. I call it "git-mkpatches".
#/bin/sh
mkdir patches/
count="1"
for i in $(git-rev-list HEAD ^ORIG_HEAD | tac)
do
git-diff-tree --pretty -p ${i} > patches/$count.diff
count=$(($count + 1))
done
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
