D Programming Language source (dmd, phobos,etc.) has moved to github
Vladimir Panteleev
vladimir at thecybershadow.net
Wed Jan 26 13:39:08 PST 2011
On Wed, 26 Jan 2011 23:36:03 +0200, Nick Sabalausky <a at a.a> wrote:
> "Vladimir Panteleev" <vladimir at thecybershadow.net> wrote in message
> news:op.vpxo9jz4tuzx1w at cybershadow.mshome.net...
>> On Wed, 26 Jan 2011 22:43:11 +0200, Nick Sabalausky <a at 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:vladimir at thecybershadow.net
More information about the Digitalmars-d-announce
mailing list