On Mon, Oct 23, 2006 at 03:44:13PM -0700 I heard the voice of Linus Torvalds, and lo! it spake thus: > > gitk (and all other logging functions) can take as its argument a > set of arbitrary revision expressions. [...] > And trust me, these are all very valid things to do, even though > you're talking about different branches. I have zero problem believing that. It seems from all accounts a wonderful swiss-army chainsaw, and while none of that power is useful to me personally in anything I'm VCS'ing at the moment, I'd feel awful shiny knowing it was sitting there waiting for me. All else being equal, I'd think more highly of a VCS with those capabilities than one without. bzr-the-program doesn't have a lot of that capability, and what it does have is rather more verbose to access. Perhaps some attribute of bzr-the-current-storage-model would make some bit of that significantly more expensive than it has to be (I don't know of any, and can't think offhand of anywhere it might hide, but that's way off my turf). But I don't understand how bzr-the-abstract-data-model makes such things impossible, or even significantly different than doing so in git. In git, you're just chopping off one DAG where another one intersects it (or similar operations). To do it in bzr, you'd do... exactly the same thing. The revnos, or the mainline, are completely useless in such an operation of course, but they don't hurt it; the tool would just just ignore them like it does the SHA-1 of files in the revision. > See? When you visualize multiple branches together, HAVING > PER-BRANCH REVISION NUMBERS IS INSANE! Yet, clearly, it's a valid > and interesting operation to do. I wouldn't be so absolutist about it, but certainly they're of extremely limited utility if of any at all in such cases. And yes, it can be an interesting operation. But what does that have to do with using revnos in other cases? You keep saying "having" where I would say "using". > No. If you "undo", you'd undo the whole history too. And if you undo > to a point that was on a branch, you'd have to re-write _all_ the > revision ID's. Well, I guess in this particular case I still don't see why you'd generally undo big hunks of a branch versus just flipping your working tree to different versions. But contrived examples are still examples, and even if so, truncate()'ing a list of numbers is a constant time operation. And even if you had to renumber totally... my $DEITY, I'd expect my old 200MHz PPro to renumber a hundred thousand rev long mainline in half a second. > > I consider it a _technical_ sign of a way of thinking about > > branches I prefer 8-} > > Quite frankly, I just don't think you understand what it means. Quite frankly, I just don't think you understand that I WANT to care about first parents. No, really. Seriously. I really really really want to. If my VCS didn't give me numbers along the mainline, I'd still care out it. If the revisions were all named SHA-1 hashes, I'd still care about it. If I had a metric quidnillion ways to cross-section and compare branches, I'd still care about it. This comes with costs. Chief among them is a restriction of my actions; I can't fast-forward branches where I care about the mainline. That's a cost. That means I have to take some care about what operations I perform. I *GLEEFULLY* pony up that cost. Because I care about the mainline, revnos can be useful. I like revnos. It has to cost SOMETHING to come up with them (though there seems to be disagreement about the size of that cost), since doing 'x+y' will always cost more than doing 'x'. I've never seen a case where that cost even appeared MEASURABLE, much less significant (things have to be pretty expensive to compare to the cost of starting up python and loading a bunch of files into it ;). So far, I've not seen the slightest hint of a cost that would make it even worth asking the question of whether the cost is worth it to me. I care about that first parent line. Therefore, I require my tool to at least _pretend_ to care. I'm not aware of any way in which the fundamental bzr structures care, but the UI is chock full of pretending. A necessary part of that pretending is not changing my mainline unless I specifically ask for it, and that means a merge-vs-pull distinction needs to be there. That's a _technical_ sign that the tool is ready to work with me the way I want to work. A lack of it is a _technical_ sign that it's not suitable. You, by your own words, don't care about the first parent line. Your tool naturally reflects this. From that perspective, *ANY* cost for maintaining such a thing is Bad And Wrong, and so you condemn it. Those condemnations will keep failing to carry any weight with me, though, as long as I care about that mainline and value the benefits I find in it. Maybe I won't always. 2 years ago, I could maybe see some benefits in DVCS, but I couldn't imagine what possible use they could ever be to me in anything I do. Today, I'm using one (if lightly by the standards of a lot of people in this discussion), and chafing at every centralized system I have to deal with. In 5 years, I may be standing beside you slugging it out at those lunatics and hacks who keep begging to pay these whopper costs, just to be able to do extra work to maintain an ordering of parents that doesn't matter for crap. Could be. I've changed my mind about far more momentous things in my life. Maybe someday I'll still care, but the OTHER advantages of a system (like git) that doesn't over all the ones that do will outweigh the advantages I gain from that distinction. Someday I might need such ultra-expressive ways of comparing branches, and bzr won't have grown them yet. Someday I might reach a point where bzr's performance due to the choice of storage structures or implementation language or developer habits or whatever else just doesn't cut the mustard, and git's does. Someday, some set of other advantages may make it worthwhile for me to give up my preciouss mainline no matter how much I might still crave it. But I can only work from today. Today, I do care. Today, it's well worth whatever I give up to get it. And I like that my tool makes that caring easy for me. -- Matthew Fuller (MF4839) | fullermd@xxxxxxxxxxxxxxx Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html