Re: : Networking

From: Andrew Morton <akpm@osdl.org>
Date: Apr 26, 2005, 19:51 UTC
Message-ID: <20050426125141.6ec38d31.akpm@osdl.org>
In-Reply-To: <Pine.LNX.4.58.0504261209470.18901@ppc970.osdl.org>

Linus Torvalds <torvalds@osdl.org> wrote:

Show 12 quoted lines

>
> 
> 
> On Tue, 26 Apr 2005, Andrew Morton wrote:
> > 
> > I don't know if it'll be successful continually merging all those trees
> > together.  The way I did this with bk was to have a separate repo for each
> > tree, but I don't think I'll want 30-40 separate git trees.
> 
> You really don't. With git, the only thing you need is one object store,
> and some way to _track_ those 30-40 separate git trees (and "track" really
> means "remember a single SHA1 name for their top-of-tree").

Petr's wrappers do all that head tracking OK (which is why I'm using a combo of those and of lower-level gittiness). They do handy remote repo tracking too.

Show 18 quoted lines

> Then you can merge any combination of the 40 in the same tree. 
> 
> You'll get confused easily, but if you do this all with tools, it 
> shouldn't be too bad.
> 
> > So hm.  I guess git did what it was supposed to do here, and that a `git
> > merge' would have removed the common patch.  But if I take the approach of
> > merging all those subsystem trees I do wonder if things will come
> > unstuck...
> 
> Well, git isn't as good at merging as BK is, and your usage sure as hell
> would be a horrible worst-case example, but it might actually work fine.  
> Git merges are _cheap_ (with a capital C, and probably H as well) when
> they work out, and quite frankly, so far they have always worked out for
> me.
> 
> But yeah, you'd be doing some pretty aggressive merging, using a tool that 
> is two weeks old. It might work. I'd be interested to know ;)

Hm. For now I might try what I have plus Jan's fancy interdiff command to remove duped patches. We'll see. I obtained a copy of Tony's ia64 diff quite happily - it didn't have any duplicates.

(It's fairly common for two subsystem maintainers to apply the same patch. With bk I was resolving that by just smashing the patches on top of each other, ignoring the rejects and refreshing the topmost patch. That approach actually resolved this linus-vs-davem dupe as well. But the duped patch was so damn BIG that it threw me. And I wasn't feeling gitty enough to go hunting about looking for the particular patch(es) which caused the problem)