Re: : Networking
- From
- Ryan Anderson <ryan@michonline.com>
- Date
- Apr 28, 2005, 03:55 UTC
- Message-ID
- <20050428035534.GB30308@mythryan2.michonline.com>
- In-Reply-To
- <Pine.LNX.4.44.0504261332540.4678-100000@wax.eds.org>
On Tue, Apr 26, 2005 at 01:35:55PM -0700, Bram Cohen wrote:
Show 18 quoted lines
> Linus Torvalds wrote: > > > On Tue, 26 Apr 2005, Andrew Morton wrote: > > > > > > 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. > > > > Oh, wow. I didn't realize that your scripts were quite _that_ stupid, and > > didn't actually take advantage of any automatic merges at all. > > > > If so, git should trivially do everything that BK ever did for you. Which > > is not saying a lot ;) > > No version control system will do a particularly good job of merging > content which got passed around outside of the system. They can be made to > sort-of handle some simple cases well, but fundamentally too much > information is getting dropped.
One thing to keep in mind, about the way Linux development works (and honestly, the way I think "git" development is currently working) is that one of the things the version control system has to provide an easy method to do is to abandon history that is messy.
For example, I'm adding a new driver, "foobar".
It uses the fancy quantum-bus, which is fairly new to the kernel. The bus driver is new, and I go off, work in my private tree for a month, fixing all kinds of quantum-entanglement related bugs, and committing as I go.
I get everything working, and submit my driver.
The quantum-bus maintainer replies and says, "Hey, I reworked the API so that you don't need to worry about all this quantum-entanglement stuff anymore, just call compensate_for_heisenberg() before doing the DMA."
I swear for a day or two, and rework my driver, and resubmit it.
Now, all that history I had, with the duplicated imlementation, and useless code is in my tree.
The current (as I understand it) policy is, "We don't want that history." This means that the developer will build a new tree (maybe), export his patch and reimport it into a clean tree, making a much simpler history graph.
What Andrew is doing isn't too far from this, in concept, it's just a lot more complicated because he's pulling something insane, like 27 seperate trees, plus several hundred stand alone patches.
So, there's a *deliberate* desire to drop history and move some content around outside of version control.
Now, the desire to pull a bunch of seperate trees, merge them, produce a diff that roughly pertains to what came in from each tree, and collect that as a patch series may be strange, but it seems to be working really well at the moment, for Linux development.
> The solution is to get everyone using the same version control system, > which is actually quite a workable solution if (a) the version control > system in question is quite nice, and (b) there isn't some deep political > reason why many people will never agree to use it.
Git (well, cogito, really) seems to be getting there awfully fast - I'm rather impressed with the speed of it, and annoyed that I haven't had the time to build up a test suite for merging!
-- Ryan Anderson sometimes Pug Majere