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

[Lutger Blijdestijn]

Nick Sabalausky wrote:

> "Lutger Blijdestijn" <lutger.blijdestijn at gmail.com> wrote in message
> news:ihn21d$2esd$1 at digitalmars.com...
>> Nick Sabalausky wrote:
>>
>>> "David Nadlinger" <see at klickverbot.at> wrote in message
>>> news:ihkub8$1ia4$1 at digitalmars.com...
>>>> On 1/24/11 10:20 PM, Nick Sabalausky wrote:
>>>>>>> Does Git really not have real revision/changeset numbers?
>>>>>>
>>>>>>[.]
>>>>>>
>>>>>
>>>>> Not that I've actually used DVCSes much yet, but my understanding is
>>>>> that the same can be set of Hg and yet Hg handles revision/changeset
>>>>> numbers just
>>>>> fine. The nice things (plural) about those is that they're both
>>>>> readable
>>>>> and
>>>>> comparable.
>>>>
>>>> Hg has no ?real revision/changeset numbers? either - there is a
>>>> more-or-less-monotonic number assigned to the various changesets, but
>>>> it's only valid for a single, *local* checkout, using them e.g. in a NG
>>>> post would be a very wrong thing to do
>>>> (http://mercurial.selenic.com/wiki/RevisionNumber).
>>>>
>>>
>>> Even without really using DVCSes it always seemed clear to me that an
>>> incremented number would be relative to a particular branch. So if you
>>> specify what branch you're talking about (which could usually just be
>>> assumed to be the main official one unless otherwise specified),
>>> shouldn't
>>> that be enough?
>>>
>>>> Git supports a relative notation as well, which is what I personally
>>>> want
>>>> to use most of the time anyway (e.g. HEAD^, master~4, something@{"1
>>>> year ago"}, .).
>>>
>>> Ah, so it *does* then? Great! Happen to have a link that explains it?
>>>
>>
>> This covers most of it to see what's possible:
>>
>> http://progit.org/book/ch6-1.html
>>
>> You can customize git log with a format string, try this for example:
>>
>> git log --pretty=format:"%h - %an, %ar : %s %d"
>>
> 
> Ahh, that's not remotely what I was hoping it was. Everything is all
> relative to the current version which means that *every* time you commit,
> *every* changeset gets completely renamed (HEAD@{5} becomes HEAD@{6},
> etc), and there doesn't appear to be any syntax to refer to the next
> changeset (only the previous), which makes it barely useful at all. And
> not only that, but they *dissapear* after a certain amount of time.
>
> Browsing through http://hginit.com/index.html, it looks like with Hg,
> everything works just as well as with SVN, the only difference being that
> you need to remember to specify which repository you're talking about
> whenever you give a number.

I see, you want a convenient name for a particular commit, is that it? But 
even the hg revision number is discouraged to be used to talk with others, 
this is from the manual: 

"It is a strictly local convenience identifier (...) Revision numbers 
referring to changesets are very likely to be different in another copy of a 
repository. Do not use them to talk about changesets with other people" 

When there is a lot of branching going on (even in a local repository) these 
revisions numbers become useless and confusing. A unique identifier is much 
more useful. You can't expect other people to piece together how the 
revision number has come to be, that is extremely brittle. 
 
> Obviously I'm not saying "DMD should have gone Hg", I'm just kinda shocked
> by how horrid Git's approach is for referring to changesets. (Personally,
> that alone would be enough to get me to use Hg instead of Git for my own
> projects. Heck, I've become pretty much sold on the idea of DVCS, but
> because of this I think I'd actually sooner use SVN for a new project than
> Git.)