On Tue, 19 Apr 2005, David Lang wrote:
> what if you turned the forest of quilt patches into a forest of git trees?
> (essentially applying each patch against the baseline seperatly) would
> this make sense or be useful?
It has a certain charm, but the fact is, it gets really messy to sort out
The thing is, there's a huge benefit to a straight-line tree: you can do
binary searching etc of patches that cause problems, and in general it's
just a lot _easier_ to work with a linear set of patches for pretty much
So yes, it's "cool" to show the fact that patches are independent and show
them as each applying to the baseline (and then you can have the "mother
of all merges" that ties them all together), but that's just a _nightmare_
when you actually try to debug things and sort things out.
So while I'm a huge proponent of parallell development, and having lots of
branches, I actually think that _linearizing_ stuff is a good thing.
So let's put it this way: parallel development and merging is wonderful as
a tool to handle true distributed development, and it's the thing that GIT
really tries to do. But once you have "local" development (like in a set
of quilt patches), the _last_ thing you want to do is try to make it look
parallel. You're much better off picking a good order, and sticking with
it. Because otherwise, 2 months down the line, you'll just look at that
tree, and what you'll want to do is to visualize them linearly anyway.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html