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

Nick Sabalausky a at a.a
Mon Jan 24 16:37:28 PST 2011


"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?

> You don't have to specify the full SHA-1 hash either, as long as it is 
> still unambiguous - for example, you could just refer to the 2.051 version 
> mentioned above as »1374« to save typing.

Typing isn't part of my concern. There's always copy-paste.

The problem I have with the hashes is that from looking at them there is 
absolutely no way to know *anything* about them. For instance, if I see 
"r172", then I *know* that's vastly newer than r17, vastly older than r538, 
immediately before r173 and immediately after r171. It actually *means* 
something and tells me about it. Granted, it would be better if it also told 
me something about its location in the branching, but at least it tells me 
*something* meaningful. But with hashes, *everything* along those lines goes 
right out the window: *any* hash could be from *anywhere*, and they all look 
the same anyway.

Things like hashes belong behind-the-scenes, not out in front as *the* 
de-facto human-facing resource locator. Which would you rather deal with 
manually: An MS-style GUID or a Java-style reverse-URI?





More information about the Digitalmars-d-announce mailing list