Re: [GIT]: Networking

Linus Torvalds <torvalds@osdl.org> wrote:
>
> 
> 
> 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.

> 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)
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html