"David Nadlinger" <s...@klickverbot.at> wrote in message
news:ihkub8$1ia4$1...@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?
