January 24, 2011
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).

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"}, …). 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.

David
January 24, 2011
> I don't know. I haven't used Hg. However, I have a hard time seeing how you could have revision numbers like subversion does

Mercurial uses hashes.
For convenience it *additionally* provides consecutive numbers which are to be used in your own *local repo only*.
January 25, 2011
"David Nadlinger" <see@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?



January 25, 2011
Nick Sabalausky wrote:

> "David Nadlinger" <see@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?
> 

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"








January 25, 2011
"Lutger Blijdestijn" <lutger.blijdestijn@gmail.com> wrote in message news:ihn21d$2esd$1@digitalmars.com...
> Nick Sabalausky wrote:
>
>> "David Nadlinger" <see@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?
>>
>
> 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.

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.)



January 25, 2011
"Nick Sabalausky" <a@a.a> wrote in message news:ihne76$4cp$1@digitalmars.com...
> "Lutger Blijdestijn" <lutger.blijdestijn@gmail.com> wrote in message news:ihn21d$2esd$1@digitalmars.com...
>> Nick Sabalausky wrote:
>>
>>> "David Nadlinger" <see@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?
>>>
>>
>> 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.
>
> 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.)
>

Additionally, Hg's approach provides a trivial way to disambiguate hash collisions. I know that Git book brushes it off as "very rare", but it's not as if nobody's ever going to run into it.



January 25, 2011
On Tue, 25 Jan 2011 23:08:13 +0200, Nick Sabalausky <a@a.a> wrote:

> 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.

Not just what repository, but what clone of the repository! It's explained in http://hginit.com/05.html. The number only makes sense for the clone of the repository you're working on right now - basically you can't tell that number to anyone, because it might mean something entirely different for them.

> 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.)

I think you need to take some time and think about it. It's impossible to use a global incrementing revision number with any DVCS! In fact, I dare to think that Hg having revision numbers is a stupid mistake that tries to make SVN users comfy, but will only lead to confusion and angst when people try to refer to revisions by their "number".

> Additionally, Hg's approach provides a trivial way to disambiguate hash
> collisions. I know that Git book brushes it off as "very rare", but it's not
> as if nobody's ever going to run into it.

Um, what method is that? Also, saying that SHA-1 hash collisions are "very rare" is a bit of an understatement.

-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net
January 25, 2011
Nick Sabalausky wrote:

> "Lutger Blijdestijn" <lutger.blijdestijn@gmail.com> wrote in message news:ihn21d$2esd$1@digitalmars.com...
>> Nick Sabalausky wrote:
>>
>>> "David Nadlinger" <see@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?
>>>
>>
>> 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.)



January 25, 2011
"Vladimir Panteleev" <vladimir@thecybershadow.net> wrote in message news:op.vpvv5sn8tuzx1w@cybershadow.mshome.net...
> On Tue, 25 Jan 2011 23:08:13 +0200, Nick Sabalausky <a@a.a> wrote:
>
>> 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.
>
> Not just what repository, but what clone of the repository!

That's the same exact concept, isn't it? My understanding is that a clone of a DVCS repository *is* a distinct DVCS repository. So, yea, like I said, you have to specify "which repository". The "common dev" repository. The "main stable repository". The "only shared repository this small project actually has". Or "Bob's repository" for what little that would be worth.


> It's explained  in http://hginit.com/05.html. The number only makes sense for the clone of  the repository you're working on right now - basically you can't tell that  number to anyone, because it might mean something entirely different for  them.
>

Yea, that's what I was looking at. The numbers for a *local* repository aren't really usable by anyone else since no one else has access to it. But it's extremely rare not to have at least one *common* repository that everyone pushes/pulls to. I see no reason why the numbers of those common repositories can't be used among multiple people, again, providing that it's understood which repository is being talked about.


>> 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.)
>
> I think you need to take some time and think about it. It's impossible to use a global incrementing revision number with any DVCS!

I don't understand why you think I'm claiming anything of the sort. I never said anything like that. I keep saying over and over and over and over and over and over and over....."changeset number **PLUS WHICH REPOSITORY (and maybe branch, depending how the given system chooses to work)**"


> In fact, I dare  to think that Hg having revision numbers is a stupid mistake that tries to  make SVN users comfy, but will only lead to confusion and angst when  people try to refer to revisions by their "number".
>

There are plenty of things about *any* DVCS that are going to confuse people who try to treat it like SVN. If that was a valid reason not to do something a certain way, then Hg/Git/etc would all have to *be* SVN.


>> Additionally, Hg's approach provides a trivial way to disambiguate hash
>> collisions. I know that Git book brushes it off as "very rare", but it's
>> not
>> as if nobody's ever going to run into it.
>
> Um, what method is that?

Version number together with being specific about which repository.


> Also, saying that SHA-1 hash collisions are "very  rare" is a bit of an understatement.
>

Point is, it's possible and it's going to happen at least to someone, and frankly, such things *have* happened. Winning the lottery and getting hit by lighting are *extremely* rare, and yet there are a *lot* of people who have had it happen. The problem is they're taking "rare" (doesn't matter what superlative is used) and pretending it's the same as "impossible". Airplane crashes and major earthquakes are extremely rare, but they sure as hell plan for what happens should such an event occur.



January 25, 2011
On 25/01/11 21:08, Nick Sabalausky wrote:
> 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.
>
> 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.)

This is the primary reason I use hg over git (that and I find it far easier to use, but that's debatable, I know loads of people that find git easier to use - guess it depends on your mindset).

For all the nay-sayers to numbers in revisions - unless you're working on huge projects with lots of developers, for the most part all the devs will have the same revision numbers. Sure, it's completely flawed, but even when you get to the stage where nice base-10 numbers aren't feasible due to all the developers having different local repositories it's still useful. In hg you'll see something like '70:5abed7016f34' - you get a rough idea where it is automatically from the number, and can look up the exact revision if you need to. It's also great for technically inclined beta testers - their revision numbers will be in sync with the repository as it's highly unlikely they'll have their own changes.

As an aside, I applaud the move to git, much needed! I may be advocating hg here, but I'm no purist, I'm perfectly happy to jump camp depending on what the developers are using... And git is a huge improvement on SVN :D

-- 
Robert
http://octarineparrot.com/