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.
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.
--
Best regards,
Vladimir mailto:vladi...@thecybershadow.net
