On Thu, Aug 11, 2005 at 12:40:48PM -0700, David S. Miller wrote: > 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.
ouch. > 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 ok, that makes sense. This is why I never offer or suggest you to pull from my tree (so far). One option might be to create a new local branch (head) for every single patch, and applying incremental fixes into that respective branch... but then there's still no easy way to create one cumulative new patch from the respective changes. > 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. Mh. It still works surprisingly well, netfilter-2.6.14 survived both of your re-base's. > 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 :-) Don't say that. the last merge was about 7-10 conflicts that had to be resolved manually, nothing more... [What have I done. I didn't wan to turn netdev into git-users *g*] -- - Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
pgprXHN3s0VcS.pgp
Description: PGP signature
