"Vladimir Panteleev" <vladi...@thecybershadow.net> wrote in message news:op.vpxqfimjtuz...@cybershadow.mshome.net... > On Wed, 26 Jan 2011 23:36:03 +0200, Nick Sabalausky <a@a.a> wrote: > >> "Vladimir Panteleev" <vladi...@thecybershadow.net> wrote in message >> news:op.vpxo9jz4tuz...@cybershadow.mshome.net... >>> On Wed, 26 Jan 2011 22:43:11 +0200, Nick Sabalausky <a@a.a> wrote: >>> >>>> 2. 35912 and 35780 are obviously related to each other in a certain >>>> way. >>>> I >>>> can tell just buy glancing that 35912 is a little over 100 commits >>>> after >>>> 35780. And I can immediately tell that they're both *far* newer than, >>>> say, 243. And far older than, say, 54928. Try doing that with hashes. >>> >>> None of these assertions hold in a DVCS repository. Merging in or >>> rebasing >>> an old branch ruins everything. >>> >> >> I don't see how merging would cause a problem. A merge is a new commit, >> so >> it would get the next new revision number just like any other new commit >> would. > > Yes, but the commit numbers lose any meaning beyond the order in which the > commits are added to the repository. That's barely useful, except when you > know they're part of the same linear development history. >
It may not as meaningful as an SVN repo that never does any branching. But it's still much more meaningful than a hash. >> And from what people have been saying, rebasing is only kosher on private >> repos so any little bit of awkwardness in there woudn't be a big deal >> (and >> I'm not sure how awkward it would be anyway since if if you're shuffling >> history around you'd *expect* the revision numbers to change since that's >> exactly what you're doing anyway). > > I meant non-destructive rebasing (not rewriting history), for example when > backporting a feature, or when applying a feature branch on top of the > latest master. > I guess I still don't see the problem there. It's still a new change that wasn't there before, hence a newly incremented revision number. And if it wants to add some meta-data referring to where it was copied over from, then ok.