D Programming Language source (dmd, phobos, etc.) has moved to github

Nick Sabalausky a at a.a
Wed Jan 26 14:00:52 PST 2011


"Vladimir Panteleev" <vladimir at thecybershadow.net> wrote in message 
news:op.vpxqfimjtuzx1w at cybershadow.mshome.net...
> 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.
>

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.





More information about the Digitalmars-d-announce mailing list