On Tue, 17 Oct 2006, Robert Collins wrote: > On Tue, 2006-10-17 at 11:20 +0200, Jakub Narebski wrote: > > > > ---- time ---> > > > > --*--*--*--*--*--*--*--*--*-- <branch> > > \ / > > \-*--X--*--/ > > > > The branch it used to be on is gone... > > In bzr 0.12 this is : > 2.1.2 > > (assuming the first * is numbered '1'.) > > These numbers are fairly stable And here, by "fairly stable", you really mean "totally idiotic", don't you? Guys, let's be blunt here, and just say you're wrong. The fact is, I've used a system that uses the same naming bzr does, and I've used it likely longer and with a bigger project than anybody has likely _ever_ used bzr for. It sounds like bzr is doing _exactly_ what bitkeeper did. Those "simple" numbers are totally idiotic. And when I say "totally idiotic", please go back up a few sentences, and read those again. I know what I'm talking about. I know probably better than anybody in the bzr camp. Those "simple" numbers are anything but. They may be short, most of the time, but when you bandy things like "-r 56" around, what you're ignoring is that for a _real_ project you actually get numbers like "1.517.3.57", which isn't really any simpler or shorter than saying "7786ce19". You still want to cut-and-paste it. And the "simple" numbers have a real downside, which is that THEY CHANGE. What happens is that somebody else started _another_ branch at revision 2, and did important work, and and they also had a "2.1.2" revision, and then they merged your work, and you merged their merge back, that "simple" revision number changed, didn't it? Suddenly "2.1.2" means something different for one of the users. We had people in the bitkeeper world that _never_ actually understood that the numbers changed. The "simple" numbers were stable enough that a lot of people thought they were real revisions, and then they were really _really_ confused when a number like "1.517.3.57" suddenly went away after a merge, and became something else instead. And yes, bitkeeper had a "real key" internally too. If you actually wanted to give a real revision, you had to give something that looked a lot like what the bzr internal revision numbers look like. Of course, most users didn't even _know_ or understand those revision numbers, so as a result, you had tons of people who used the "simple" thing (which was what "bk log" and all other tools would show), and since it worked quite often, they thought it was ok. And then sometimes it didn't work at all, or it "worked" by giving the wrong commit, and it was just a total disaster. Something that works "most of the time" is not simple to use. It's just a way to make people _believe_ it is simple, and then be really confused when it doesn't work. So trust me, naming things so that the name depend on the local shape of the history is idiotic. I _know_. Been there, done that. The thing is, when I designed git, I actually had years of experience working with a big project in a truly distributed manner. I _knew_ that handling renames specially is a bad idea (not that you should even need to have used BK to know that). And I _knew_ that the simple revision numbers aren't real and just cause confusion. Linus - 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