www.digitalmars.com         C & C++   DMDScript  

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

reply Walter Bright <newshound2 digitalmars.com> writes:
https://github.com/organizations/D-Programming-Language

We're all learning how to use github, but by most accounts it seems to be the 
best available system for the diverse group of people who work on it.
Jan 23 2011
next sibling parent reply David Wang <osx.david live.com> writes:
Dear Walter,

I went to the github and try to download the source, I found that
the latest version on github is the old version.

for example:

druntime - Downloads: dmd-2.042
Phobos -   Downloads: phobos-2.046
DMD -      Downloads: dmd-2.046

I think the actural latest version of D should be 2.051.

Why github can not showing the 2.051 version(dmd, phobos,
druntime, and so on.) ?
Jan 23 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
David Wang wrote:

 Dear Walter,
 
 I went to the github and try to download the source, I found that
 the latest version on github is the old version.
 
 for example:
 
 druntime - Downloads: dmd-2.042
 Phobos -   Downloads: phobos-2.046
 DMD -      Downloads: dmd-2.046
 
 I think the actural latest version of D should be 2.051.
 
 Why github can not showing the 2.051 version(dmd, phobos,
 druntime, and so on.) ?


I think it is because the tags were never done properly on svn, either.
Jan 23 2011
parent reply Johannes Pfau <spam example.com> writes:
Walter Bright wrote:

David Wang wrote:

 Dear Walter,
=20
 I went to the github and try to download the source, I found that
 the latest version on github is the old version.
=20
 for example:
=20
 druntime - Downloads: dmd-2.042
 Phobos -   Downloads: phobos-2.046
 DMD -      Downloads: dmd-2.046
=20
 I think the actural latest version of D should be 2.051.
=20
 Why github can not showing the 2.051 version(dmd, phobos,
 druntime, and so on.) ?


I think it is because the tags were never done properly on svn, either.


It's still possible to add the tags (see
http://progit.org/book/ch2-6.html "Tagging Later") but we'd have to
know the commits used for the releases. I guess there's
no easy way to figure out which commits were used for the releases?

--=20
Johannes Pfau
Jan 24 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 24 Jan 2011 09:00:21 -0500, Johannes Pfau <spam example.com> wrote:


 Walter Bright wrote:

 David Wang wrote:

 Dear Walter,

 I went to the github and try to download the source, I found that
 the latest version on github is the old version.

 for example:

 druntime - Downloads: dmd-2.042
 Phobos -   Downloads: phobos-2.046
 DMD -      Downloads: dmd-2.046

 I think the actural latest version of D should be 2.051.

 Why github can not showing the 2.051 version(dmd, phobos,
 druntime, and so on.) ?


 I think it is because the tags were never done properly on svn, either.


 It's still possible to add the tags (see
 http://progit.org/book/ch2-6.html "Tagging Later") but we'd have to
 know the commits used for the releases. I guess there's
 no easy way to figure out which commits were used for the releases?


All source is included in the compiler.  It's simply a matter of doing a  
directory compare of the code against source control.  The date released  
should narrow it down to a manageable level.

I have done it in the past  
(http://www.dsource.org/projects/druntime/changeset/272)  In fact, it  
looks like I was the last one to tag druntime :)

Some script-fu could probably fill in all the holes automatically...

-Steve
Jan 24 2011
parent reply Johannes Pfau <spam example.com> writes:
Steven Schveighoffer wrote:

On Mon, 24 Jan 2011 09:00:21 -0500, Johannes Pfau <spam example.com>
wrote:


 Walter Bright wrote:

 David Wang wrote:

 Dear Walter,

 I went to the github and try to download the source, I found that
 the latest version on github is the old version.

 for example:

 druntime - Downloads: dmd-2.042
 Phobos -   Downloads: phobos-2.046
 DMD -      Downloads: dmd-2.046

 I think the actural latest version of D should be 2.051.

 Why github can not showing the 2.051 version(dmd, phobos,
 druntime, and so on.) ?


 I think it is because the tags were never done properly on svn,
 either.


 It's still possible to add the tags (see
 http://progit.org/book/ch2-6.html "Tagging Later") but we'd have to
 know the commits used for the releases. I guess there's
 no easy way to figure out which commits were used for the releases?


All source is included in the compiler.  It's simply a matter of doing
a directory compare of the code against source control.  The date
released should narrow it down to a manageable level.

I have done it in the past =20
(http://www.dsource.org/projects/druntime/changeset/272)  In fact, it =20
looks like I was the last one to tag druntime :)

Some script-fu could probably fill in all the holes automatically...

-Steve


OK, here are some revisions:
DMD:
2.051 seems to be revision 1374ba96fa5516d9595fa61b09015197a8b84385
  Note: The changelog on the website says release date Nov 7 but it's
  more like 20th December.
  Note2: The git repository contains a object.h file in that revision
  which isn't in the dmd zip.
2.050 50fb3d60811b203ac50a0d9169bf15a28881c9b5
  Note: The git repository contains a argtypes.c file in that revision
  which isn't in the dmd zip.
2.049 ab38d58ecb78924d631f7f77863fff2a6c234eb6
2.048 bcf720fe079fd979fa9e81f63ab2de3dde9284dc
2.047 ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48
  Note: In the dmd zip, there are 7 additional lines in
  root/root.c. Those were later added to the repository, but
  ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48 seems to be the correct
  commit.

--=20
Johannes Pfau
Jan 24 2011
next sibling parent J C Calvarese <jccalvarese gmail.com> writes:
== Quote from Johannes Pfau (spam example.com)'s article

 --Sig_/hgUpRkpzV0eGcapavO0e/z1
 Content-Type: text/plain; charset=US-ASCII
 Content-Transfer-Encoding: quoted-printable
 Steven Schveighoffer wrote:


...


All source is included in the compiler.  It's simply a matter of doing
a directory compare of the code against source control.  The date
released should narrow it down to a manageable level.

I have done it in the past =20
(http://www.dsource.org/projects/druntime/changeset/272)  In fact, it =20
looks like I was the last one to tag druntime :)

Some script-fu could probably fill in all the holes automatically...

-Steve


 OK, here are some revisions:
 DMD:
 2.051 seems to be revision 1374ba96fa5516d9595fa61b09015197a8b84385
   Note: The changelog on the website says release date Nov 7 but it's
   more like 20th December.
   Note2: The git repository contains a object.h file in that revision
   which isn't in the dmd zip.
 2.050 50fb3d60811b203ac50a0d9169bf15a28881c9b5
   Note: The git repository contains a argtypes.c file in that revision
   which isn't in the dmd zip.
 2.049 ab38d58ecb78924d631f7f77863fff2a6c234eb6
 2.048 bcf720fe079fd979fa9e81f63ab2de3dde9284dc
 2.047 ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48
   Note: In the dmd zip, there are 7 additional lines in
   root/root.c. Those were later added to the repository, but
   ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48 seems to be the correct
   commit.


Someone might find this wiki page of use:
http://www.prowiki.org/wiki4d/wiki.cgi?action=browse&id=History/Year2010

It links to the release announcement for each version of DMD in 2010. (Earlier
years are on other pages. I guess there hasn't been
a release in 2011 yet.)

I think the dates on this page are based on when the release announcement was
sent rather than what the changelog might have. I'm
not sure which time zone was used (and it might be inconsistent), so it might
be off a day compared to what you'd expect, but you
can look at the timestamp on Walter's messages by following the links.

Since it's a wiki, anyone can make corrections (or add more information) if
they'd like to help.

jcc7
Jan 24 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 24 Jan 2011 10:34:18 -0500, Johannes Pfau <spam example.com> wrote:


 Steven Schveighoffer wrote:

 On Mon, 24 Jan 2011 09:00:21 -0500, Johannes Pfau <spam example.com>
 wrote:


 Walter Bright wrote:

 David Wang wrote:

 Dear Walter,

 I went to the github and try to download the source, I found that
 the latest version on github is the old version.

 for example:

 druntime - Downloads: dmd-2.042
 Phobos -   Downloads: phobos-2.046
 DMD -      Downloads: dmd-2.046

 I think the actural latest version of D should be 2.051.

 Why github can not showing the 2.051 version(dmd, phobos,
 druntime, and so on.) ?


 I think it is because the tags were never done properly on svn,
 either.


 It's still possible to add the tags (see
 http://progit.org/book/ch2-6.html "Tagging Later") but we'd have to
 know the commits used for the releases. I guess there's
 no easy way to figure out which commits were used for the releases?


 All source is included in the compiler.  It's simply a matter of doing
 a directory compare of the code against source control.  The date
 released should narrow it down to a manageable level.

 I have done it in the past
 (http://www.dsource.org/projects/druntime/changeset/272)  In fact, it
 looks like I was the last one to tag druntime :)

 Some script-fu could probably fill in all the holes automatically...

 -Steve


 OK, here are some revisions:
 DMD:
 2.051 seems to be revision 1374ba96fa5516d9595fa61b09015197a8b84385
   Note: The changelog on the website says release date Nov 7 but it's
   more like 20th December.


That is probably a doc bug.  When creating the 'next' version in the  
changelog, Walter arbitrarily puts a date in there as a placeholder  
(usually the date he does that), and looks like he forgot to change it.   
Probably we should get into the practice of putting TBD instead of a date.


   Note2: The git repository contains a object.h file in that revision
   which isn't in the dmd zip.
 2.050 50fb3d60811b203ac50a0d9169bf15a28881c9b5
   Note: The git repository contains a argtypes.c file in that revision
   which isn't in the dmd zip.
 2.049 ab38d58ecb78924d631f7f77863fff2a6c234eb6
 2.048 bcf720fe079fd979fa9e81f63ab2de3dde9284dc
 2.047 ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48
   Note: In the dmd zip, there are 7 additional lines in
   root/root.c. Those were later added to the repository, but
   ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48 seems to be the correct
   commit.


At this point, I would say, tag those versions.  Its very unlikely that  
someone ever needs one of these old revs anyways.  I'm glad you were able  
to do all this work, thanks!

-Steve
Jan 24 2011
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Johannes Pfau" <spam example.com> wrote in message 
news:20110124163418.3880a154 jpf-Satellite-A100...

 OK, here are some revisions:
 DMD:
 2.051 seems to be revision 1374ba96fa5516d9595fa61b09015197a8b84385
   Note: The changelog on the website says release date Nov 7 but it's
   more like 20th December.
   Note2: The git repository contains a object.h file in that revision
   which isn't in the dmd zip.
 2.050 50fb3d60811b203ac50a0d9169bf15a28881c9b5
   Note: The git repository contains a argtypes.c file in that revision
   which isn't in the dmd zip.
 2.049 ab38d58ecb78924d631f7f77863fff2a6c234eb6
 2.048 bcf720fe079fd979fa9e81f63ab2de3dde9284dc
 2.047 ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48
   Note: In the dmd zip, there are 7 additional lines in
   root/root.c. Those were later added to the repository, but
   ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48 seems to be the correct
   commit.


Does Git really not have real revision/changeset numbers?
Jan 24 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday 24 January 2011 13:04:27 Nick Sabalausky wrote:

 "Johannes Pfau" <spam example.com> wrote in message
 news:20110124163418.3880a154 jpf-Satellite-A100...
 

 OK, here are some revisions:
 DMD:
 2.051 seems to be revision 1374ba96fa5516d9595fa61b09015197a8b84385
 
   Note: The changelog on the website says release date Nov 7 but it's
   more like 20th December.
   Note2: The git repository contains a object.h file in that revision
   which isn't in the dmd zip.
 
 2.050 50fb3d60811b203ac50a0d9169bf15a28881c9b5
 
   Note: The git repository contains a argtypes.c file in that revision
   which isn't in the dmd zip.
 
 2.049 ab38d58ecb78924d631f7f77863fff2a6c234eb6
 2.048 bcf720fe079fd979fa9e81f63ab2de3dde9284dc
 2.047 ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48
 
   Note: In the dmd zip, there are 7 additional lines in
   root/root.c. Those were later added to the repository, but
   ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48 seems to be the correct
   commit.


 
 Does Git really not have real revision/changeset numbers?


It's SHA1 hashes. And actually, considering how prevalent branching and merging 
is with git (_everyone_ has their own fork of the repository), I question that 
revision/changeset numbers would work anyway. The fact that you can reorder 
commits wouldn't help either. So, no. Git doesn't have revision or changeset 
numbers.

However, the git commands where you give it a revision's SHA1 only need enough 
of the SHA1 to uniquely identify it, so you rarely need to type the whole thing 
even when you're giving it the SHA1. Now, I suppose that makes things like the 
revision number for dmd 2.049 uglier, but git is very much distributed and not 
centralized in terms of how it's set up, so revision numbers in the SVN sense 
just wouldn't make sense.

- Jonathan M Davis
Jan 24 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.911.1295903507.4748.digitalmars-d-announce puremagic.com...

 On Monday 24 January 2011 13:04:27 Nick Sabalausky wrote:

 "Johannes Pfau" <spam example.com> wrote in message
 news:20110124163418.3880a154 jpf-Satellite-A100...


 OK, here are some revisions:
 DMD:
 2.051 seems to be revision 1374ba96fa5516d9595fa61b09015197a8b84385

   Note: The changelog on the website says release date Nov 7 but it's
   more like 20th December.
   Note2: The git repository contains a object.h file in that revision
   which isn't in the dmd zip.

 2.050 50fb3d60811b203ac50a0d9169bf15a28881c9b5

   Note: The git repository contains a argtypes.c file in that revision
   which isn't in the dmd zip.

 2.049 ab38d58ecb78924d631f7f77863fff2a6c234eb6
 2.048 bcf720fe079fd979fa9e81f63ab2de3dde9284dc
 2.047 ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48

   Note: In the dmd zip, there are 7 additional lines in
   root/root.c. Those were later added to the repository, but
   ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48 seems to be the correct
   commit.


 Does Git really not have real revision/changeset numbers?


 It's SHA1 hashes. And actually, considering how prevalent branching and 
 merging
 is with git (_everyone_ has their own fork of the repository), I question 
 that
 revision/changeset numbers would work anyway. The fact that you can 
 reorder
 commits wouldn't help either. So, no. Git doesn't have revision or 
 changeset
 numbers.

 However, the git commands where you give it a revision's SHA1 only need 
 enough
 of the SHA1 to uniquely identify it, so you rarely need to type the whole 
 thing
 even when you're giving it the SHA1. Now, I suppose that makes things like 
 the
 revision number for dmd 2.049 uglier, but git is very much distributed and 
 not
 centralized in terms of how it's set up, so revision numbers in the SVN 
 sense
 just wouldn't make sense.


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.
Jan 24 2011
next sibling parent Jesse Phillips <jessekphillips+D gmail.com> writes:
Nick Sabalausky Wrote:


 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.


Here, how about a quote:

http://mercurial.selenic.com/wiki/RevisionNumber

"Pitfalls

"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. Use the changeset ID instead."

So I wouldn't really say that is "just fine."
Jan 24 2011
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, January 24, 2011 13:20:44 Nick Sabalausky wrote:

 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message
 news:mailman.911.1295903507.4748.digitalmars-d-announce puremagic.com...
 

 On Monday 24 January 2011 13:04:27 Nick Sabalausky wrote:

 "Johannes Pfau" <spam example.com> wrote in message
 news:20110124163418.3880a154 jpf-Satellite-A100...
 

 OK, here are some revisions:
 DMD:
 2.051 seems to be revision 1374ba96fa5516d9595fa61b09015197a8b84385
 
   Note: The changelog on the website says release date Nov 7 but it's
   more like 20th December.
   Note2: The git repository contains a object.h file in that revision
   which isn't in the dmd zip.
 
 2.050 50fb3d60811b203ac50a0d9169bf15a28881c9b5
 
   Note: The git repository contains a argtypes.c file in that revision
   which isn't in the dmd zip.
 
 2.049 ab38d58ecb78924d631f7f77863fff2a6c234eb6
 2.048 bcf720fe079fd979fa9e81f63ab2de3dde9284dc
 2.047 ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48
 
   Note: In the dmd zip, there are 7 additional lines in
   root/root.c. Those were later added to the repository, but
   ad4ae4a4fd3dbdb591ebc288378a7200d2ed6d48 seems to be the correct
   commit.


 
 Does Git really not have real revision/changeset numbers?


 
 It's SHA1 hashes. And actually, considering how prevalent branching and
 merging
 is with git (_everyone_ has their own fork of the repository), I question
 that
 revision/changeset numbers would work anyway. The fact that you can
 reorder
 commits wouldn't help either. So, no. Git doesn't have revision or
 changeset
 numbers.
 
 However, the git commands where you give it a revision's SHA1 only need
 enough
 of the SHA1 to uniquely identify it, so you rarely need to type the whole
 thing
 even when you're giving it the SHA1. Now, I suppose that makes things
 like the
 revision number for dmd 2.049 uglier, but git is very much distributed
 and not
 centralized in terms of how it's set up, so revision numbers in the SVN
 sense
 just wouldn't make sense.


 
 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.


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. You could certainly have 
numbers which weren't hashes or in base 16, but you can't just increment the 
version number each time, or you'll run into conflicts when you go to merge. 
Maybe the Hg guys figured out something smart that manages. I don't know. But
git 
uses the SHA1 hash, which is supposedly unique and avoids any version numbers 
clashing. It also serves as a means of guaranteeing that your repository hasn't 
been damaged, since if the repo's state doesn't match its SHA1, then it's not 
valid (due to data corruption or tampering or whatever).

- Jonathan M Davis
Jan 24 2011
parent Trass3r <un known.com> writes:
 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*.
Jan 24 2011
prev sibling parent reply David Nadlinger <see klickverbot.at> writes:
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
Jan 24 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"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?
Jan 24 2011
parent reply Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
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"
Jan 25 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"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.)
Jan 25 2011
next sibling parent "Nick Sabalausky" <a a.a> writes:
"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.
Jan 25 2011
prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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
Jan 25 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"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.
Jan 25 2011
next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 25/01/11 22:28, Nick Sabalausky wrote:

 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)**"


Person A has a repository with one branch, 'default' and has made two 
commits. The current revision number is 1.
Person B clones the repository and creates a branch, 'ver2', and makes 
two commits. The revision number in his repository is now 3, it is still 
1 in person A's.
Person A makes a commit, his revision 2. B switches back to the 
'default' branch, and makes another commit.  His revision 4. A pulls 
from the default branch, now B's revision 4 == A's revision 3.

It's very easy for the revision numbers to get out of sync like this. 
Now if person B mentioned revision 2, A will not see the same commit as 
B when looking at it, and has no way of specifying to look in B's 
repository - A doesn't have access to B's 'ver2' branch until he pulls 
it (or B pushes it). There are any number of other cirumstances which 
could easily cause this in a DVCS, and this is without reordering 
commits etc.

This said, I still like them, and they are really useful for small 
projects :)

-- 
Robert
http://octarineparrot.com/
Jan 25 2011
parent "Nick Sabalausky" <a a.a> writes:
"Robert Clipsham" <robert octarineparrot.com> wrote in message 
news:ihnk80$fsf$1 digitalmars.com...

 On 25/01/11 22:28, Nick Sabalausky wrote:

 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)**"


 Person A has a repository with one branch, 'default' and has made two 
 commits. The current revision number is 1.
 Person B clones the repository and creates a branch, 'ver2', and makes two 
 commits. The revision number in his repository is now 3, it is still 1 in 
 person A's.
 Person A makes a commit, his revision 2. B switches back to the 'default' 
 branch, and makes another commit.  His revision 4. A pulls from the 
 default branch, now B's revision 4 == A's revision 3.

 It's very easy for the revision numbers to get out of sync like this.


Right, I already understood all of that. But consider the following scenario 
(And I realize that neither Hg nor Git work exactly like this, but until 
Lutger mentioned the extra details in "git describe --tags" it sounded like 
Git was much further away from this than Hg is):

Adam starts a repository:

    dvcs://joes-fancy-dvcs-hosting.org/users/Adam/SuperApp

It's Adam's project, so that could be considered the main "official" repo. 
Adam makes five commits in the default "default" branch. His current 
revision is:

    dvcs://joes-fancy-dvcs-hosting.org/users/Adam/SuperApp/default/4

Behind the scenes, that revision is associated with an SHA-1 hash of 
"df3a9...". This same revision, thus, could also be referred to as:

    dvcs://joes-fancy-dvcs-hosting.org/users/Adam/SuperApp/hashes/df3a9...

But usually that's only used behind-the-scenes. Adam never cares about it 
and neither do any of the other SuperApp contributors. But the DVCS often 
uses it internally. (Are the hashes normally assiciated with a specific 
branch? If so, then just consider it "SuperApp/default/hashes/df3a9..." 
instead of "SuperApp/hashes/df3a9...").

Now, along comes Bob who clones Adam's SuperApp repo. Bob's copy of the same 
revision is:

    dvcs://joes-fancy-dvcs-hosting.org/users/Bob/SuperApp/default/4

Naturally, he also has the same hash as Adam:

    dvcs://joes-fancy-dvcs-hosting.org/users/Bob/SuperApp/hashes/df3a9...

Then Adam and Bob start making commits, updates, pushes, pulls, etc, and 
their revision numbers get out-of-sync. Adam and Bob are talking on a 
newsgroup, and Adam mentions a super-cool improvement he just committed:

    dvcs://joes-fancy-dvcs-hosting.org/users/Adam/SuperApp/default/81

Adam doesn't know this, but that just happens to have the hash "78ac1..." 
and thus be AKA:

    dvcs://joes-fancy-dvcs-hosting.org/users/Adam/SuperApp/hashes/78ac1...

Bob wants Adam's new change, so he tells his DVCS to merge in:

    dvcs://joes-fancy-dvcs-hosting.org/users/Adam/SuperApp/default/81

No problem. Bob didn't ask his DVCS for "r81", he asked it for "Adam's r81". 
This revision now becomes Bob's:

    dvcs://joes-fancy-dvcs-hosting.org/users/Bob/SuperApp/default/117
    dvcs://joes-fancy-dvcs-hosting.org/users/Bob/SuperApp/hashes/78ac1...

Since Adam announced this on a NG, Carlos also saw it and grabbed the new 
change:

    dvcs://carlos-coder.co.uk/SuperApp/default/94
    dvcs://carlos-coder.co.uk/SuperApp/hashes/78ac1...

They all start to use it, but Bob discovers a critical problem with it. So 
Bob tells the NG to avoid:

    dvcs://joes-fancy-dvcs-hosting.org/users/Adam/SuperApp/default/81

Or, Bob might have referred to it with his own revision instead (Maybe 
Adam's account was temporarily down):

    dvcs://joes-fancy-dvcs-hosting.org/users/Bob/SuperApp/default/117

So Carlos tells his DVCS to revert that URI. To do this, Carlos's DVCS looks 
up Adam's or Bob's URI and finds the associated hash: "78ac1...". Then it 
looks at Carlos's own copy of the repo, sees the active branch is "default", 
and finds the revision in "default" associated with the hash "78ac1...", 
which is:

    dvcs://carlos-coder.co.uk/SuperApp/default/94

Which then gets reverted.
Jan 25 2011
prev sibling next sibling parent reply Ulrik Mikaelsson <ulrik.mikaelsson gmail.com> writes:
 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 "mai=


n

 stable repository". The "only shared repository this small project actual=


ly

 has". Or "Bob's repository" for what little that would be worth.


Mostly a side-note, but in many DVCS:es (git in particular, but both
bzr and hg has it too), history rewriting is allowed, even encouraged
under some particular circumstances. In that case, the SHA-1 revision
will CERTAINLY change, while even repo+number is not very reliable.
Some kernel-branches are maintained like that, for example.

Furthermore, a related hg-anecdote; Personally, for my work-flow I
often use history-rewriting to jump around, amending patches, rebasing
them before pushing, etc. I've become very accustomed to it, and find
it extremely useful. When trying out hg a while back (to make patches
for LDC IIRC), the attempted linear-history was actually one of my
biggest disappointments. I quickly ended up in a situation where all
my patches looked like a zig-zag-stacked hodgepodge of stuff, many of
them not intended to even keep in the repo. When reading the docs
about it, the only useful suggestion I found was to create a new repo,
and cherry-pick what I wanted from the old. It's possible this were
mostly due to my inexperience with Hg, but it strengthened my
conviction that the unrealistic linear-numbers of a non-linear history
are really just shoe-horning in something for newbie-comfort, but
quite off as a model. For me, It is the deal-breaker for hg.


 I don't understand why you think I'm claiming anything of the sort. I nev=


er

 said anything like that. I keep saying over and over and over and over an=


d

 over and over and over....."changeset number **PLUS WHICH REPOSITORY (and
 maybe branch, depending how the given system chooses to work)**"


How should you linearly number the two chains A > B > C and A > D > C
? Is it A, B, D, C or A, D, B, C? Should they be inter-vowen by
commit-time, or what?


 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.


Again, version-number + repo is not 100% when history-rewrite is possible.


 Also, saying that SHA-1 hash collisions are "very =C2=A0rare" is a bit o=




f 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 ha=


ve

 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". Airpla=


ne

 crashes and major earthquakes are extremely rare, but they sure as hell p=


lan

 for what happens should such an event occur.


Getting hit by lightning isn't really on the same scale as SHA-1 collisions=
.

According to Wolfram Alpha, the odds of being struck by lightning in a
given year is one in 750000. If I've understood things roughly right,
(probabilities aren't my strong side) the best possible attack for
SHA-1 requires 2^52 attempts (Note: intentional attack, pure random
chance is likely MUCH higher). That means that, given a very big
project of 1 million commits (2^20, by comparison Linux is at 232k
atm), the chance of intentionally hitting a collision is 1 in 2^32 =3D
4billion.

Suffice to say, comparatively there might be a prospering market for
current-insulating clothing.

I guess, when every household on earth are running it's own
kernel-project, git might have to upgrade to SHA-512. (Hg too, btw. I
think the REAL, internal revision-id:s for HG is sha-1 too, aren't
they?)
Jan 25 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Ulrik Mikaelsson" <ulrik.mikaelsson gmail.com> wrote in message 
news:mailman.949.1295999711.4748.digitalmars-d-announce puremagic.com...

 Again, version-number + repo is not 100% when history-rewrite is possible.


"History-rewrite" is new to me. Does that just mean branching off from a 
past revision? If not, do you have a link that explains it?
Jan 25 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, January 25, 2011 16:50:03 Nick Sabalausky wrote:

 "Ulrik Mikaelsson" <ulrik.mikaelsson gmail.com> wrote in message
 news:mailman.949.1295999711.4748.digitalmars-d-announce puremagic.com...
 

 Again, version-number + repo is not 100% when history-rewrite is
 possible.


 
 "History-rewrite" is new to me. Does that just mean branching off from a
 past revision? If not, do you have a link that explains it?


You can do stuff like re-order and squash commits. Look at the man page for git-
rebase.

- Jonathan M Davis
Jan 25 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.950.1296005459.4748.digitalmars-d-announce puremagic.com...

 On Tuesday, January 25, 2011 16:50:03 Nick Sabalausky wrote:

 "Ulrik Mikaelsson" <ulrik.mikaelsson gmail.com> wrote in message
 news:mailman.949.1295999711.4748.digitalmars-d-announce puremagic.com...


 Again, version-number + repo is not 100% when history-rewrite is
 possible.


 "History-rewrite" is new to me. Does that just mean branching off from a
 past revision? If not, do you have a link that explains it?


 You can do stuff like re-order and squash commits. Look at the man page 
 for git-
 rebase.


Ok, I just took a look at it here:

http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html

Maybe it's just my inexperience with DVCSes, but everything in there seems 
like the sort of thing I would consider much better off accomplished by just 
simply creating a new branch that re-applies changesets from an existing 
branch (or in most cases of removing changesets, committing a new changeset 
that undoes the undesired ones) instead of screwing around with the history. 
And if some joker's been spamming a repo with a bunch of garbage commits, 
then ok, maybe have something to delete that old junk branch. But aside from 
that sort of special case, I don't see what good can come from encouraging 
removal of the old branch versus just simply adding a new one or committing 
an "undo" changeset. In other words, history-rewriting seems to trade in the 
reliability of a stable history for...apperently some benefit that I'm 
having trouble seeing (Just so that you can? I kinda doubt that would be the 
reason though, especially if Torvalds is heavily involved.)

Ulrick mentioned that history rewriting is "encouraged under some particular 
circumstances". What circumstances would those be?
Jan 25 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday 25 January 2011 18:24:56 Nick Sabalausky wrote:

 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message
 news:mailman.950.1296005459.4748.digitalmars-d-announce puremagic.com...
 

 On Tuesday, January 25, 2011 16:50:03 Nick Sabalausky wrote:

 "Ulrik Mikaelsson" <ulrik.mikaelsson gmail.com> wrote in message
 news:mailman.949.1295999711.4748.digitalmars-d-announce puremagic.com...
 

 Again, version-number + repo is not 100% when history-rewrite is
 possible.


 
 "History-rewrite" is new to me. Does that just mean branching off from a
 past revision? If not, do you have a link that explains it?


 
 You can do stuff like re-order and squash commits. Look at the man page
 for git-
 rebase.


 
 Ok, I just took a look at it here:
 
 http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html
 
 Maybe it's just my inexperience with DVCSes, but everything in there seems
 like the sort of thing I would consider much better off accomplished by
 just simply creating a new branch that re-applies changesets from an
 existing branch (or in most cases of removing changesets, committing a new
 changeset that undoes the undesired ones) instead of screwing around with
 the history. And if some joker's been spamming a repo with a bunch of
 garbage commits, then ok, maybe have something to delete that old junk
 branch. But aside from that sort of special case, I don't see what good
 can come from encouraging removal of the old branch versus just simply
 adding a new one or committing an "undo" changeset. In other words,
 history-rewriting seems to trade in the reliability of a stable history
 for...apperently some benefit that I'm having trouble seeing (Just so that
 you can? I kinda doubt that would be the reason though, especially if
 Torvalds is heavily involved.)
 
 Ulrick mentioned that history rewriting is "encouraged under some
 particular circumstances". What circumstances would those be?


I don't know how encouraged it is or isn't. The way I use it most often is to
do 
multiple small commits as I'm working on something and then squash them into
one 
when I'm done. I could also see circumstances where it would be advantageous to 
reorder some commits - particularly if you wanted to create a branch with some 
of the newer changesets but not some of the ones just prior to them. So, I
think 
that it's a highly useful feature. Still, beyond squashing multiple smaller 
commits together when I'm done working on something, I don't see a whole lot of 
value in using rebase regularly. Perhaps there's a good reason for it that I'm 
not aware of though.

Regardless, rebasing changes the tree, resulting in new SHA1 hashes for each 
commit, so it's not like you can screw up a repository without anyone who has 
branched off from it noticing. So, I'm not sure how abusable it really is on 
anything other than a one man project. So, while I can understand why rebase 
could be considered a potential problem, I think that it's well worth having.

Still, I don't really know what the "encouraged under some particular 
circumstances" would be referring to.

- Jonathan M Davis
Jan 25 2011
prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wed, 26 Jan 2011 04:24:56 +0200, Nick Sabalausky <a a.a> wrote:


 Maybe it's just my inexperience with DVCSes, but everything in there  
 seems
 like the sort of thing I would consider much better off accomplished by  
 just
 simply creating a new branch that re-applies changesets from an existing
 branch (or in most cases of removing changesets, committing a new  
 changeset
 that undoes the undesired ones) instead of screwing around with the  
 history.


History rewriting in public repositories is very rare. It's a hassle for  
everyone - if someone forked off the rewritten branch, they'll need to  
rebase that branch on the new one. However, history rewriting can be  
extremely useful for local commits. Here are a few typical use cases:

1) You made a typo in a commit message a few commits ago.
2) You wish to fix something in a local commit from a while ago. This can  
be done by editing the commit directly (as above), or by making the fix as  
a new commit, an merging the two commits together.
3) You wish to clean up and reorder your development history into atomic  
commits, ready to be sent upstream as a patchset (very common with  
open-source projects).
4) You wish to split a subdirectory of the repository, along with all of  
its history, to a separate repository.
etc.

git provides many ways of automating common history edits - see the man  
page for git-filter-branch, for some examples.

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
Jan 25 2011
parent "Nick Sabalausky" <a a.a> writes:
"Vladimir Panteleev" <vladimir thecybershadow.net> wrote in message 
news:op.vpwb01qttuzx1w cybershadow.mshome.net...

 On Wed, 26 Jan 2011 04:24:56 +0200, Nick Sabalausky <a a.a> wrote:


 Maybe it's just my inexperience with DVCSes, but everything in there 
 seems
 like the sort of thing I would consider much better off accomplished by 
 just
 simply creating a new branch that re-applies changesets from an existing
 branch (or in most cases of removing changesets, committing a new 
 changeset
 that undoes the undesired ones) instead of screwing around with the 
 history.


 History rewriting in public repositories is very rare. It's a hassle for 
 everyone - if someone forked off the rewritten branch, they'll need to 
 rebase that branch on the new one. However, history rewriting can be 
 extremely useful for local commits. Here are a few typical use cases:

 1) You made a typo in a commit message a few commits ago.
 2) You wish to fix something in a local commit from a while ago. This can 
 be done by editing the commit directly (as above), or by making the fix as 
 a new commit, an merging the two commits together.
 3) You wish to clean up and reorder your development history into atomic 
 commits, ready to be sent upstream as a patchset (very common with 
 open-source projects).
 4) You wish to split a subdirectory of the repository, along with all of 
 its history, to a separate repository.
 etc.

 git provides many ways of automating common history edits - see the man 
 page for git-filter-branch, for some examples.


Ahh, I see. That does sound useful then. But that does mean that any 
implications that would have on an incremented changeset number shouldn't be 
a problem in practice since it's mainly just done on private repos.
Jan 25 2011
prev sibling parent Russel Winder <russel russel.org.uk> writes:
On Tue, 2011-01-25 at 21:24 -0500, Nick Sabalausky wrote:
[ . . . ]

 Ulrick mentioned that history rewriting is "encouraged under some particu=


lar=20

 circumstances". What circumstances would those be?


Rebasing/rewriting of private, never published repositories is
absolutely fine, and is encouraged for preparing a repository for
creation of changesets/patches where it is not possible to simply
publish the repository and issue a pull request.

In all other circumstances rebasing/rewriting is discouraged.  Well
actually as close to being banned as it is possible to get.
Rebasing/rewriting an already published repository is a catastrophic
event that ruins relationships with clones (due to the history
rewriting!).

Git repositories used as writing clients to Subversion repositories
(using git-svn) have to do rebasing as an integral part of the writing
to the Subversion repository.  This means they have to be personal
clients only.  Read-only is a way of bridging of course since there is
no rebasing.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jan 26 2011
prev sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wed, 26 Jan 2011 00:28:22 +0200, Nick Sabalausky <a a.a> wrote:


 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.


OK, I see your point. However, I would avoid using such a way to refer to  
commits, where mistaking one half of it may still point towards a commit,  
however a completely unrelated one.


 But it's extremely rare not to have at least one *common* repository that
 everyone pushes/pulls to.


Um, why do you think people wrote DVCS systems? They could have just  
souped up SVN with local commits and proper merging etc. (I heard SVN was  
going to do that anyway.)


 I don't understand why you think I'm claiming anything of the sort.


I was under the impression you thought commit numbers somehow magically  
propagated themselves throughout all clones of the repository ("distinct  
repository was ambiguous"), since I saw no point in referring to a  
revision number that's only valid for the copy on your hard drive. I  
didn't think you implied the scenario of making your repository remotely  
accessible.


 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.


An analogy to this mis-feature would be D compiling valid C code in a  
subtly different manner than C. D explicitly avoids this, with good reason.


 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.


I think you're more likely to simultaneously get hit by a lightning and  
crushed by a falling airplane during an earthquake than encountering a  
hash collision in your repository.

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
Jan 25 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Vladimir Panteleev" <vladimir thecybershadow.net> wrote in message 
news:op.vpv8w0pctuzx1w cybershadow.mshome.net...

 On Wed, 26 Jan 2011 00:28:22 +0200, Nick Sabalausky <a a.a> wrote:


 I don't understand why you think I'm claiming anything of the sort.


 I was under the impression you thought commit numbers somehow magically 
 propagated themselves throughout all clones of the repository ("distinct 
 repository was ambiguous"), since I saw no point in referring to a 
 revision number that's only valid for the copy on your hard drive. I 
 didn't think you implied the scenario of making your repository remotely 
 accessible.


Well, normally there's at least *some* repository that's remotely 
accessible, otherwise nobody would (or even could) be doing any cloning or 
pulling or pushing (and you'd be left with a single-user private SVN with 
better merging).

I agree that referring to a revision number that's only valid on your own 
local repo is of questionable benefit if it's not remotely accessible. 
However, I do think it makes sense to refer to a revision number on whatever 
remotely accessible repo inevitably does exist.
Jan 25 2011
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wed, 26 Jan 2011 04:40:03 +0200, Nick Sabalausky <a a.a> wrote:


 Well, normally there's at least *some* repository that's remotely
 accessible, otherwise nobody would (or even could) be doing any cloning  
 or
 pulling or pushing (and you'd be left with a single-user private SVN with
 better merging).


Thus the question is - does Hg even allow you to (easily) inspect revision  
numbers of an arbitrary remote repository? Are they preserved while  
cloning? Also, how would you look up the revision number of a specific  
commit in another repository? By its hash? Why not just give other people  
the hash directly? :)

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
Jan 25 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Vladimir Panteleev" <vladimir thecybershadow.net> wrote in message 
news:op.vpwco52etuzx1w cybershadow.mshome.net...

 On Wed, 26 Jan 2011 04:40:03 +0200, Nick Sabalausky <a a.a> wrote:


 Well, normally there's at least *some* repository that's remotely
 accessible, otherwise nobody would (or even could) be doing any cloning 
 or
 pulling or pushing (and you'd be left with a single-user private SVN with
 better merging).


 Thus the question is - does Hg even allow you to (easily) inspect revision 
 numbers of an arbitrary remote repository?


Yes. Exhibits A, B and C:

- Joel's HgInit: http://hginit.com/01.html (Do a text-search inside the page 
for "changeset:")
- Trac's Hg browser: http://www.dsource.org/projects/ddmd/browser
- Hg's built-in html browser: 
http://hg.dsource.org/projects/ddmd/rev/13cf8da225ce

It seems to be typical convention in the Hg world for changesets to be 
displayed in the format "revision:hash". I would imagine you could use 
either one by itself to refer to a specific commit (don't know for certain 
though, haven't used it enough).


 Are they preserved while cloning?


Maybe someone with real Hg experience could answer this. I'd be surprised if 
the answer is "no", since it is supposed to be a "clone" after all, but I 
really don't know.



 Also, how would you look up the revision number of a specific  commit in 
 another repository? By its hash?


Not sure what you mean. A commit in a given repo has both a revision number 
and a hash so I'd image you could use either one to look up the other.

If you mean that you have a revision number in your local repo and want to 
find the revision number of the same changeset in a remote repo, then yes, 
you would have to use the hash as a go-between. But I see no technical 
reason why it shouldn't be possible for that to entirely do-able 
behind-the-scenes as long as there's a way to specify a specific remote 
repository. Whether or not Hg currently has such an automatic ability, I 
have no idea.



 Why not just give other people the hash directly? :)


official public repo: r184
official public repo: r185
...etc.

Versus:

9f4e5ac4f0a3
13cf8da225ce
...etc.

I don't know about other people, but I find the former to be far more 
readable, far more descriptive, and actually possible to reason about. Sure, 
the latter can be copy-pasted and it still refers to the same changeset, but 
other then that it's meaningless gibberish.
Jan 25 2011
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
As far as I can tell hg stores both a commit number and a hash, e.g.:


 D:\dev\projects\project>hg log -r :


changeset:   0:08d729df85c9
user:        Andrej Mitrovic <andrej.mitrovich gmail.com>
date:        Fri Dec 22 00:07:02 2010 +0200
summary:     bla bla

changeset:   1:61cfebefee15
user:        Andrej Mitrovic <andrej.mitrovich gmail.com>
date:        Fri Dec 24 21:42:45 2010 +0100
summary:     bla bla

I don't know the details, I've just started using hg recently.
Jan 25 2011
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
Nick Sabalausky Wrote:


 official public repo: r184
 official public repo: r185
 ...etc.
 
 Versus:
 
 9f4e5ac4f0a3
 13cf8da225ce
 ...etc.
 
 I don't know about other people, but I find the former to be far more 
 readable, far more descriptive, and actually possible to reason about. Sure, 
 the latter can be copy-pasted and it still refers to the same changeset, but 
 other then that it's meaningless gibberish.


LOL, this meaningless gibberish is usually called a unique identifier.
Jan 26 2011
next sibling parent reply David Wang <osx.david live.com> writes:
== Repost the article of Kagamin (spam here.lot)
== Posted at 2011/01/26 07:31 to digitalmars.D.announce


Nick Sabalausky Wrote:



 official public repo: r184
 official public repo: r185
 ...etc.

 Versus:

 9f4e5ac4f0a3
 13cf8da225ce
 ...etc.

 I don't know about other people, but I find the former to be far more
 readable, far more descriptive, and actually possible to reason about. Sure,
 the latter can be copy-pasted and it still refers to the same changeset, but
 other then that it's meaningless gibberish.





LOL, this meaningless gibberish is usually called a unique identifier.


And I use git to download the source from github.com for "druntime".
But I found that in it subdirectory "import", there is only contain "std" and
"object.di", missed the "core" subdirectory for druntime.
Why?

Or, the "core" subdirectory exists on the github.com, but we can no see it?
or there have some other way except git to download it?

waiting for kindly help.

Best regards
David.
Jan 26 2011
parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wed, 26 Jan 2011 15:10:08 +0200, David Wang <osx.david live.com> wrote:


 And I use git to download the source from github.com for "druntime".
 But I found that in it subdirectory "import", there is only contain  
 "std" and
 "object.di", missed the "core" subdirectory for druntime.
 Why?

 Or, the "core" subdirectory exists on the github.com, but we can no see  
 it?
 or there have some other way except git to download it?

 waiting for kindly help.

 Best regards
 David.


The source code of druntime is under the src/core directory[1]. The .di  
files in the import directory are generated automatically during the  
build[2].

   [1]:  
https://github.com/D-Programming-Language/druntime/tree/master/src/core
   [2]:  
https://github.com/D-Programming-Language/druntime/blob/master/win32.mak#L361

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
Jan 26 2011
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Kagamin" <spam here.lot> wrote in message 
news:ihp46m$b3$1 digitalmars.com...

 Nick Sabalausky Wrote:


 official public repo: r184
 official public repo: r185
 ...etc.

 Versus:

 9f4e5ac4f0a3
 13cf8da225ce
 ...etc.

 I don't know about other people, but I find the former to be far more
 readable, far more descriptive, and actually possible to reason about. 
 Sure,
 the latter can be copy-pasted and it still refers to the same changeset, 
 but
 other then that it's meaningless gibberish.


 LOL, this meaningless gibberish is usually called a unique identifier.


I don't care what it's called. *Both* of the above examples are obviously 
unique. Repo name + revision number *does* uniquey identify one and only one 
changeset. Are you deliberately missing that point?
Jan 26 2011
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wed, 26 Jan 2011 22:46:44 +0200, Nick Sabalausky <a a.a> wrote:


 Are you deliberately missing that point?


I think everyone's just annoyed how you're fiercely defending an idea that  
has a single advantage (terseness - I consider hashes unique in practice),  
but a whole slew of disadvantages, and then criticizing Git & co. for  
being "horrid" because they don't use your idea.

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
Jan 26 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Vladimir Panteleev" <vladimir thecybershadow.net> wrote in message 
news:op.vpxphnlmtuzx1w cybershadow.mshome.net...

 On Wed, 26 Jan 2011 22:46:44 +0200, Nick Sabalausky <a a.a> wrote:


 Are you deliberately missing that point?


 I think everyone's just annoyed how you're fiercely defending an idea that 
 has a single advantage (terseness - I consider hashes unique in practice), 
 but a whole slew of disadvantages,


Terseness is not at all the only advantage. As I've said before, you can 
reason about them, compare them, and get a general idea of "where" they are 
in the history. I don't think merging or "changing the past" conflict with 
that. And I'm really not seeing any non-trivial disadvantages.



 and then criticizing Git & co. for  being "horrid" because they don't use 
 your idea.


What? Are you actually trying to claim that defending/promoting one's own 
idea when another idea exists is a *bad* thing? Seriously?

If we're going to go that absurd route, I can just make up the claim people 
are ganging up on me for having an idea that just happens to be different 
from Git's world-view. If Git does something one way then that *must* be the 
best way, right? Anything else is obviously just heresy, right? Bring on the 
stakes and torches, we're going to Salem!!
Jan 26 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, January 26, 2011 13:54:04 Nick Sabalausky wrote:

 "Vladimir Panteleev" <vladimir thecybershadow.net> wrote in message
 news:op.vpxphnlmtuzx1w cybershadow.mshome.net...
 

 On Wed, 26 Jan 2011 22:46:44 +0200, Nick Sabalausky <a a.a> wrote:

 Are you deliberately missing that point?


 
 I think everyone's just annoyed how you're fiercely defending an idea
 that has a single advantage (terseness - I consider hashes unique in
 practice), but a whole slew of disadvantages,


 
 Terseness is not at all the only advantage. As I've said before, you can
 reason about them, compare them, and get a general idea of "where" they are
 in the history. I don't think merging or "changing the past" conflict with
 that. And I'm really not seeing any non-trivial disadvantages.
 

 and then criticizing Git & co. for  being "horrid" because they don't use
 your idea.


 
 What? Are you actually trying to claim that defending/promoting one's own
 idea when another idea exists is a *bad* thing? Seriously?
 
 If we're going to go that absurd route, I can just make up the claim people
 are ganging up on me for having an idea that just happens to be different
 from Git's world-view. If Git does something one way then that *must* be
 the best way, right? Anything else is obviously just heresy, right? Bring
 on the stakes and torches, we're going to Salem!!


LOL. I think that part of what it comes down to is that you're making a big
deal 
out of what other people don't consider to be a big deal at all. Personally, I 
don't care much about the revision number. Having incrementally increasing ones 
might be nice, but if you don't have them, oh well. Obviously, you feel much 
more strongly about it.

Personally, I'm not about to claim that git does everything the best way 
possible, but I find it much more pleasant to deal with than svn. Other 
distributed VC systems may be better. There may be a better way that hasn't
been 
found yet. I don't know. But I _do_ find git to be a major improvement over svn.

- Jonathan M Davis
Jan 26 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.974.1296080574.4748.digitalmars-d-announce puremagic.com...

 On Wednesday, January 26, 2011 13:54:04 Nick Sabalausky wrote:

 "Vladimir Panteleev" <vladimir thecybershadow.net> wrote in message
 news:op.vpxphnlmtuzx1w cybershadow.mshome.net...


 On Wed, 26 Jan 2011 22:46:44 +0200, Nick Sabalausky <a a.a> wrote:

 Are you deliberately missing that point?


 I think everyone's just annoyed how you're fiercely defending an idea
 that has a single advantage (terseness - I consider hashes unique in
 practice), but a whole slew of disadvantages,


 Terseness is not at all the only advantage. As I've said before, you can
 reason about them, compare them, and get a general idea of "where" they 
 are
 in the history. I don't think merging or "changing the past" conflict 
 with
 that. And I'm really not seeing any non-trivial disadvantages.


 and then criticizing Git & co. for  being "horrid" because they don't 
 use
 your idea.


 What? Are you actually trying to claim that defending/promoting one's own
 idea when another idea exists is a *bad* thing? Seriously?

 If we're going to go that absurd route, I can just make up the claim 
 people
 are ganging up on me for having an idea that just happens to be different
 from Git's world-view. If Git does something one way then that *must* be
 the best way, right? Anything else is obviously just heresy, right? Bring
 on the stakes and torches, we're going to Salem!!


 LOL. I think that part of what it comes down to is that you're making a 
 big deal
 out of what other people don't consider to be a big deal at all.


Heh, fair enough :)


 Personally, I
 don't care much about the revision number. Having incrementally increasing 
 ones
 might be nice, but if you don't have them, oh well. Obviously, you feel 
 much
 more strongly about it.


I tend to be really bothered by "steps backwards" that I don't see as being 
necessary. Seems to be a common theme with me.
Jan 26 2011
parent reply Bill Baxter <wbaxter gmail.com> writes:
Mercurial gives every revision two numbers:

"""
changeset: This field has the format of a number, followed by a colon,
followed by a hexadecimal (or=A0hex) string. These are=A0identifiers=A0for
the changeset. The hex string is a unique identifier: the same hex
string will always refer to the same changeset in every copy of this
repository. The number is shorter and easier to type than the hex
string, but it isn't unique: the same number in two different clones
of a repository may identify different changesets.
"""
example--
changeset:   0:0a04b987be5a

http://hgbook.red-bean.com/read/a-tour-of-mercurial-the-basics.html --
see section: "A Tour Through History"

Is that the kind of thing you're wanting?

--bb

On Wed, Jan 26, 2011 at 2:37 PM, Nick Sabalausky <a a.a> wrote:

 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message
 news:mailman.974.1296080574.4748.digitalmars-d-announce puremagic.com...

 On Wednesday, January 26, 2011 13:54:04 Nick Sabalausky wrote:

 "Vladimir Panteleev" <vladimir thecybershadow.net> wrote in message
 news:op.vpxphnlmtuzx1w cybershadow.mshome.net...


 On Wed, 26 Jan 2011 22:46:44 +0200, Nick Sabalausky <a a.a> wrote:

 Are you deliberately missing that point?


 I think everyone's just annoyed how you're fiercely defending an ide=








a

 that has a single advantage (terseness - I consider hashes unique in
 practice), but a whole slew of disadvantages,


 Terseness is not at all the only advantage. As I've said before, you c=






an

 reason about them, compare them, and get a general idea of "where" the=






y

 are
 in the history. I don't think merging or "changing the past" conflict
 with
 that. And I'm really not seeing any non-trivial disadvantages.


 and then criticizing Git & co. for =A0being "horrid" because they do=








n't

 use
 your idea.


 What? Are you actually trying to claim that defending/promoting one's =






own

 idea when another idea exists is a *bad* thing? Seriously?

 If we're going to go that absurd route, I can just make up the claim
 people
 are ganging up on me for having an idea that just happens to be differ=






ent

 from Git's world-view. If Git does something one way then that *must* =






be

 the best way, right? Anything else is obviously just heresy, right? Br=






ing

 on the stakes and torches, we're going to Salem!!


 LOL. I think that part of what it comes down to is that you're making a
 big deal
 out of what other people don't consider to be a big deal at all.


 Heh, fair enough :)


 Personally, I
 don't care much about the revision number. Having incrementally increas=




ing

 ones
 might be nice, but if you don't have them, oh well. Obviously, you feel
 much
 more strongly about it.


 I tend to be really bothered by "steps backwards" that I don't see as bei=


ng

 necessary. Seems to be a common theme with me.
Jan 26 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Bill Baxter" <wbaxter gmail.com> wrote in message 
news:mailman.977.1296083661.4748.digitalmars-d-announce puremagic.com...

Mercurial gives every revision two numbers:

Is that the kind of thing you're wanting?


Yea, and that's pretty much the original thing I was saying: It's nice that 
Hg seems to have it, but Git doesn't appear to be particularly interested in 
it.
Jan 27 2011
next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Thu, Jan 27, 2011 at 1:13 PM, Nick Sabalausky <a a.a> wrote:

 "Bill Baxter" <wbaxter gmail.com> wrote in message
 news:mailman.977.1296083661.4748.digitalmars-d-announce puremagic.com...

Mercurial gives every revision two numbers:

Is that the kind of thing you're wanting?


 Yea, and that's pretty much the original thing I was saying: It's nice that
 Hg seems to have it, but Git doesn't appear to be particularly interested in
 it.


I think it's very handy for all the reasons you said.  I don't think
I've every had to use a big hex string when dealing with mercurial.
Maybe once or twice max.  Most of the stuff you do with repo history
as an individual developer is all about the local copy of the tree on
your system.  Globally unique identifiers aren't needed for that.  It
looks like Bzr does something similar.  Not sure why Git hasn't gotten
this particular nicety.

--bb
Jan 27 2011
prev sibling next sibling parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Nick Sabalausky wrote:

 "Bill Baxter" <wbaxter gmail.com> wrote in message=20
 news:mailman.977.1296083661.4748.digitalmars-d-announce puremagic.com..=


=2E

 Mercurial gives every revision two numbers:

 Is that the kind of thing you're wanting?


=20
 Yea, and that's pretty much the original thing I was saying: It's nice =


that=20

 Hg seems to have it, but Git doesn't appear to be particularly interest=


ed in=20

 it.=20
=20


	Of course, Git does not have it! Svn has it so it *must* be a bad
idea ;)

		Jerome

PS: FWIW, I agree with you. Plus, there is another use case where
sequential number are very useful: each time you want to operate on
a past revision in your own repository (e.g "hg up n" or "hg diff -r
n"), it is much easier to designate that revision with a sequential
number than with the hash.
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Jan 27 2011
prev sibling parent reply Russel Winder <russel russel.org.uk> writes:
On Thu, 2011-01-27 at 13:33 -0800, Bill Baxter wrote:

 On Thu, Jan 27, 2011 at 1:13 PM, Nick Sabalausky <a a.a> wrote:


[ . . . ]

 Yea, and that's pretty much the original thing I was saying: It's nice =




that

 Hg seems to have it, but Git doesn't appear to be particularly interest=




ed in

 it.


=20
 I think it's very handy for all the reasons you said.  I don't think
 I've every had to use a big hex string when dealing with mercurial.
 Maybe once or twice max.  Most of the stuff you do with repo history
 as an individual developer is all about the local copy of the tree on
 your system.  Globally unique identifiers aren't needed for that.  It
 looks like Bzr does something similar.  Not sure why Git hasn't gotten
 this particular nicety.


Bazaar does indeed have revision numbers per branch.  Note that branch
and repository is a different concept in Bazaar, unlike Git and
Mercurial where they are fundamentally the same.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jan 28 2011
next sibling parent Mafi <mafi example.org> writes:
Am 28.01.2011 12:30, schrieb Russel Winder:

 On Thu, 2011-01-27 at 13:33 -0800, Bill Baxter wrote:

 On Thu, Jan 27, 2011 at 1:13 PM, Nick Sabalausky<a a.a>  wrote:


 [ . . . ]

 Yea, and that's pretty much the original thing I was saying: It's nice that
 Hg seems to have it, but Git doesn't appear to be particularly interested in
 it.


 I think it's very handy for all the reasons you said.  I don't think
 I've every had to use a big hex string when dealing with mercurial.
 Maybe once or twice max.  Most of the stuff you do with repo history
 as an individual developer is all about the local copy of the tree on
 your system.  Globally unique identifiers aren't needed for that.  It
 looks like Bzr does something similar.  Not sure why Git hasn't gotten
 this particular nicety.


 Bazaar does indeed have revision numbers per branch.  Note that branch
 and repository is a different concept in Bazaar, unlike Git and
 Mercurial where they are fundamentally the same.


I don't know Git but in Mercurial speech a branch is what you get when 
using the 'hg branch' command. It's like a tag but a commit can only 
belongs to exactly one branch ('default' is the default branch). All 
commits to all branches are put together in one repository.

Mafi
Jan 28 2011
prev sibling parent reply Leandro Lucarella <luca llucax.com.ar> writes:
Russel Winder, el 28 de enero a las 11:30 me escribiste:

 On Thu, 2011-01-27 at 13:33 -0800, Bill Baxter wrote:

 On Thu, Jan 27, 2011 at 1:13 PM, Nick Sabalausky <a a.a> wrote:


 [ . . . ]

 Yea, and that's pretty much the original thing I was saying: It's nice that
 Hg seems to have it, but Git doesn't appear to be particularly interested in
 it.


 
 I think it's very handy for all the reasons you said.  I don't think
 I've every had to use a big hex string when dealing with mercurial.
 Maybe once or twice max.  Most of the stuff you do with repo history
 as an individual developer is all about the local copy of the tree on
 your system.  Globally unique identifiers aren't needed for that.  It
 looks like Bzr does something similar.  Not sure why Git hasn't gotten
 this particular nicety.


 
 Bazaar does indeed have revision numbers per branch.  Note that branch
 and repository is a different concept in Bazaar, unlike Git and
 Mercurial where they are fundamentally the same.


WRONG about Git.

AFAIK only in Darcs branch and repository is the same.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
You can try the best you can
If you try the best you can
The best you can is good enough
Jan 28 2011
parent reply Russel Winder <russel russel.org.uk> writes:
On Fri, 2011-01-28 at 12:43 -0300, Leandro Lucarella wrote:

 Russel Winder, el 28 de enero a las 11:30 me escribiste:


[ . . . ]

 Bazaar does indeed have revision numbers per branch.  Note that branch
 and repository is a different concept in Bazaar, unlike Git and
 Mercurial where they are fundamentally the same.


=20
 WRONG about Git.


Depends what you thought I was saying . . .=20


 AFAIK only in Darcs branch and repository is the same.


. . . I think you misunderstood what I meant by my statement.

What I was trying to say was that Git and Mercurial have effectively the
same ideas of repository and branch (at least from a surface usage
perspective -- there are significant differences if you delve deeply).
Bazaar has a very different idea of what branch and repository are.  So
in this respect Git and Mercurial are in the same equivalence class and
Bazaar is in a different one.  I have no idea where Darcs would sit, I
have never used it beyond trying to compile Haskell this time last year.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jan 28 2011
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Russel Winder wrote:

 On Fri, 2011-01-28 at 12:43 -0300, Leandro Lucarella wrote:

 Russel Winder, el 28 de enero a las 11:30 me escribiste:


 [ . . . ]

 Bazaar does indeed have revision numbers per branch.  Note that branc=






h

 and repository is a different concept in Bazaar, unlike Git and
 Mercurial where they are fundamentally the same.


 WRONG about Git.


=20
 Depends what you thought I was saying . . .=20
=20

 AFAIK only in Darcs branch and repository is the same.


=20
 . . . I think you misunderstood what I meant by my statement.
=20
 What I was trying to say was that Git and Mercurial have effectively th=


e

 same ideas of repository and branch (at least from a surface usage
 perspective -- there are significant differences if you delve deeply).
 Bazaar has a very different idea of what branch and repository are.  So=



 in this respect Git and Mercurial are in the same equivalence class and=



 Bazaar is in a different one.  I have no idea where Darcs would sit, I
 have never used it beyond trying to compile Haskell this time last year=


=2E

=20


	In Mercurial (and AFAIK Git), branches and repositories are
completely different concepts. A repository is a folder on your hard
drive. A branch is a history line inside a repository so it's not
that different from Bazaar. The only difference I see is that Bazaar
allows you to clone a single branch (i.e to create a repository that
will only contain that single branch) whereas a clone of a Mercurial
repository will always contain all the branches that the parent had
(don't know about Git).

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Jan 29 2011
parent reply Russel Winder <russel russel.org.uk> writes:
On Sat, 2011-01-29 at 11:18 +0100, "J=C3=A9r=C3=B4me M. Berger" wrote:
[ . . . ]

 	In Mercurial (and AFAIK Git), branches and repositories are
 completely different concepts. A repository is a folder on your hard
 drive. A branch is a history line inside a repository so it's not


Definitely, this is not at issue.  The way Git and Mercurial store
information about branches and tags within a repository is very
different.  This leads to a few observable differences in the way
branches and commits behave, but in the main there is similarity not
difference.  Caveat Git's index of course.


 that different from Bazaar. The only difference I see is that Bazaar
 allows you to clone a single branch (i.e to create a repository that
 will only contain that single branch) whereas a clone of a Mercurial
 repository will always contain all the branches that the parent had
 (don't know about Git).


This is not quite the right view of Bazaar.  In Bazaar, the branch is
the only thing that exists: each branch is a standalone entity that may
or may not have a working tree.  Bazaar also has shared repositories
which can act as containers of branches, allowing related branches to
share common information thereby saving resources.  This is a very, very
different concept of repository compared to Mercurial or Git.  In Bazaar
you do not branch repositories, you branch branches -- which may (or may
not) be stored in repositories.  As you say with Git and Mercurial you
clone repositories.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jan 29 2011
parent reply foobar <foo bar.com> writes:
Russel Winder Wrote:


 On Sat, 2011-01-29 at 11:18 +0100, "Jérôme M. Berger" wrote:
 [ . . . ]

 	In Mercurial (and AFAIK Git), branches and repositories are
 completely different concepts. A repository is a folder on your hard
 drive. A branch is a history line inside a repository so it's not


 
 Definitely, this is not at issue.  The way Git and Mercurial store
 information about branches and tags within a repository is very
 different.  This leads to a few observable differences in the way
 branches and commits behave, but in the main there is similarity not
 difference.  Caveat Git's index of course.
 

 that different from Bazaar. The only difference I see is that Bazaar
 allows you to clone a single branch (i.e to create a repository that
 will only contain that single branch) whereas a clone of a Mercurial
 repository will always contain all the branches that the parent had
 (don't know about Git).


 
 This is not quite the right view of Bazaar.  In Bazaar, the branch is
 the only thing that exists: each branch is a standalone entity that may
 or may not have a working tree.  Bazaar also has shared repositories
 which can act as containers of branches, allowing related branches to
 share common information thereby saving resources.  This is a very, very
 different concept of repository compared to Mercurial or Git.  In Bazaar
 you do not branch repositories, you branch branches -- which may (or may
 not) be stored in repositories.  As you say with Git and Mercurial you
 clone repositories.
 
 -- 
 Russel.
 =============================================================================
 Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
 London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
 


The conceptual difference described above seems to me more of an insignificant
minor implementation detail than anything else. 

A git repository can contain one or more branches and you obviously can have
more than one repository so this boils down to your personal workflow
preferences. 
In other words you can have multiple repositories for the same project and just
use them as branches. Git also provides sub-module support such that one
repository contains other repositories. 
Also, while "git clone" indeed copies all the upstream branches, it's also
simple to track just a specific branch (or any subset) of the upstream
branches. It's just a matter of doing a git init with the relevant options
instead of relying on the default git clone behavior.
Jan 29 2011
parent Russel Winder <russel russel.org.uk> writes:
On Sat, 2011-01-29 at 09:49 -0500, foobar wrote:
[ . . . ]

 The conceptual difference described above seems to me more of an insignif=


icant minor implementation detail than anything else.=20

Not at all.  But I am really not going to argue the point any further.
D has chosen Git, which is fine.


 A git repository can contain one or more branches and you obviously can h=


ave more than one repository so this boils down to your personal workflow p=
references.=20

 In other words you can have multiple repositories for the same project an=


d just use them as branches. Git also provides sub-module support such that=
 one repository contains other repositories.=20

 Also, while "git clone" indeed copies all the upstream branches, it's als=


o simple to track just a specific branch (or any subset) of the upstream br=
anches. It's just a matter of doing a git init with the relevant options in=
stead of relying on the default git clone behavior.=20

Yes, but this (except tracking branches) applies to Mercurial as well.
And mostly to Bazaar.  However note the above.

Tracking branches are probably the single most useful thing in Git
compared to Mercurial and Bazaar.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jan 29 2011
prev sibling parent Kagamin <spam here.lot> writes:
Nick Sabalausky Wrote:


 "Kagamin" <spam here.lot> wrote in message 
 news:ihp46m$b3$1 digitalmars.com...

 Nick Sabalausky Wrote:


 official public repo: r184
 official public repo: r185
 ...etc.

 Versus:

 9f4e5ac4f0a3
 13cf8da225ce
 ...etc.

 I don't know about other people, but I find the former to be far more
 readable, far more descriptive, and actually possible to reason about. 
 Sure,
 the latter can be copy-pasted and it still refers to the same changeset, 
 but
 other then that it's meaningless gibberish.


 LOL, this meaningless gibberish is usually called a unique identifier.


 
 I don't care what it's called. *Both* of the above examples are obviously 
 unique. Repo name + revision number *does* uniquey identify one and only one 
 changeset. Are you deliberately missing that point?


Well, I was talking more about the "gibberish" statement. I was surprised how a
programmer calls unique identifier - a well known concept - a gibberish.

As to revision numbers, well, it could be a nice feature to support hash
identifiers with any attached text, which is just ignored by git, but helps
people think about them... does hg work this way, I wonder?
Jan 27 2011
prev sibling parent reply Kagamin <spam here.lot> writes:
Nick Sabalausky Wrote:


 official public repo: r184
 official public repo: r185
 ...etc.
 
 Versus:
 
 9f4e5ac4f0a3
 13cf8da225ce
 ...etc.
 
 I don't know about other people, but I find the former to be far more 
 readable, far more descriptive, and actually possible to reason about. Sure, 
 the latter can be copy-pasted and it still refers to the same changeset, but 
 other then that it's meaningless gibberish.


A little example: today I commited changeset 35912, and 35780 - 10 day ago. Try
to recall these random-looking numbers after reading a couple of posts in this
NG.
Jan 26 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Kagamin" <spam here.lot> wrote in message 
news:ihpjji$115f$1 digitalmars.com...

 Nick Sabalausky Wrote:


 official public repo: r184
 official public repo: r185
 ...etc.

 Versus:

 9f4e5ac4f0a3
 13cf8da225ce
 ...etc.

 I don't know about other people, but I find the former to be far more
 readable, far more descriptive, and actually possible to reason about. 
 Sure,
 the latter can be copy-pasted and it still refers to the same changeset, 
 but
 other then that it's meaningless gibberish.


 A little example: today I commited changeset 35912, and 35780 - 10 day 
 ago. Try to recall these random-looking numbers after reading a couple of 
 posts in this NG.


1. That's obviously a *lot* easier than 9f4e5ac4f0a3 and 13cf8da225ce

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.
Jan 26 2011
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wed, 26 Jan 2011 22:43:11 +0200, Nick Sabalausky <a 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.

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
Jan 26 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Vladimir Panteleev" <vladimir thecybershadow.net> wrote in message 
news:op.vpxo9jz4tuzx1w cybershadow.mshome.net...

 On Wed, 26 Jan 2011 22:43:11 +0200, Nick Sabalausky <a 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.

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).
Jan 26 2011
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wed, 26 Jan 2011 23:36:03 +0200, Nick Sabalausky <a a.a> wrote:


 "Vladimir Panteleev" <vladimir thecybershadow.net> wrote in message
 news:op.vpxo9jz4tuzx1w cybershadow.mshome.net...

 On Wed, 26 Jan 2011 22:43:11 +0200, Nick Sabalausky <a 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.


 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.

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
Jan 26 2011
parent "Nick Sabalausky" <a a.a> writes:
"Vladimir Panteleev" <vladimir thecybershadow.net> wrote in message 
news:op.vpxqfimjtuzx1w cybershadow.mshome.net...

 On Wed, 26 Jan 2011 23:36:03 +0200, Nick Sabalausky <a a.a> wrote:


 "Vladimir Panteleev" <vladimir thecybershadow.net> wrote in message
 news:op.vpxo9jz4tuzx1w cybershadow.mshome.net...

 On Wed, 26 Jan 2011 22:43:11 +0200, Nick Sabalausky <a 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.
Jan 26 2011
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Vladimir Panteleev wrote:

 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.


A version number is fundamentally linear, and so will not work very well on any 
sort of revision graph that is not a line. As soon as you branch or fork, it 
breaks down.
Jan 25 2011
prev sibling parent reply Don <nospam nospam.com> writes:
Vladimir Panteleev wrote:

 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!


I think this is a fallacy. It only applies if you
(1) *completely disallow* any centralisation -- which I don't think ever 
happens in practice!
and (2) demand that cloning a repository be an entirely read-only 
operation (so that the repository doesn't know how many times it has 
been cloned)
and (3) demand that the revision numbers behave exactly as they do in svn.

The SHA1 hashes are how many bits??? Enough for one commit from every 
person on earth, every few minutes, for hundreds of years!!!! That's a 
ridiculously inefficient method of identifying changesets.
Looks like a strawman argument to me. "It can't be done", but only 
because unnecessary requirements have been added.
Jan 25 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday 25 January 2011 20:33:35 Don wrote:

 Vladimir Panteleev wrote:

 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!


 
 I think this is a fallacy. It only applies if you
 (1) *completely disallow* any centralisation -- which I don't think ever
 happens in practice!
 and (2) demand that cloning a repository be an entirely read-only
 operation (so that the repository doesn't know how many times it has
 been cloned)
 and (3) demand that the revision numbers behave exactly as they do in svn.
 
 The SHA1 hashes are how many bits??? Enough for one commit from every
 person on earth, every few minutes, for hundreds of years!!!! That's a
 ridiculously inefficient method of identifying changesets.
 Looks like a strawman argument to me. "It can't be done", but only
 because unnecessary requirements have been added.


The main reason for the SHA1 is to verify that the repository hasn't been 
tampered with or corrupted. I suspect that Linus decided to just use it as the 
identifier for the changeset, because then you only have one number to worry 
about, not two (the hash and the changeset number). And given the difficulties 
with regards to incremental revision numbers in a distributed VCS (particularly 
one which allows for changes to the revision history), I can understand
deciding 
to just not bother with them. Whether that was the best decision or not is 
another matter. Regardless, I don't think that SHA1 was picked as a changeset
ID 
because of how many revision numbers it can hold.

- Jonathan M Davis
Jan 25 2011
prev sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wed, 26 Jan 2011 06:33:35 +0200, Don <nospam nospam.com> wrote:


 I think this is a fallacy. It only applies if you
 (1) *completely disallow* any centralisation -- which I don't think ever  
 happens in practice!


What about the Linux kernel? There's Linus's git repo, and lots of repos  
maintained by others (e.g. Linux distros). The other distros are not a  
superset of Linus's repo, they have their own branches with various  
project-specific patches and backports. Git was written for this  
specifically.


 and (2) demand that cloning a repository be an entirely read-only  
 operation (so that the repository doesn't know how many times it has  
 been cloned)
 and (3) demand that the revision numbers behave exactly as they do in  
 svn.


Then you're suggesting that the commit identifiers basically contain the  
clone history?

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
Jan 26 2011
parent reply Don <nospam nospam.com> writes:
Vladimir Panteleev wrote:

 On Wed, 26 Jan 2011 06:33:35 +0200, Don <nospam nospam.com> wrote:
 

 I think this is a fallacy. It only applies if you
 (1) *completely disallow* any centralisation -- which I don't think 
 ever happens in practice!


 
 What about the Linux kernel? There's Linus's git repo, and lots of repos 
 maintained by others (e.g. Linux distros). The other distros are not a 
 superset of Linus's repo, they have their own branches with various 
 project-specific patches and backports. Git was written for this 
 specifically.


Yes, but each distro has a trunk, in which all commits are ordered by 
time. There's always an official version of every branch.


 

 and (2) demand that cloning a repository be an entirely read-only 
 operation (so that the repository doesn't know how many times it has 
 been cloned)
 and (3) demand that the revision numbers behave exactly as they do in 
 svn.


 
 Then you're suggesting that the commit identifiers basically contain the 
 clone history?


Yes, I think it could be done that way. Identifier would be composed of 
clonenumber+commitnumber. Where it is the location of the original 
change. Yes, there are difficulties with this scheme, but I think they 
are the same challenges as for implementing merges on a centralised VCS 
such as Subversion. I don't think there's anything insurmountable.
Jan 26 2011
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wed, 26 Jan 2011 23:22:34 +0200, Don <nospam nospam.com> wrote:


 Vladimir Panteleev wrote:

 On Wed, 26 Jan 2011 06:33:35 +0200, Don <nospam nospam.com> wrote:


 I think this is a fallacy. It only applies if you
 (1) *completely disallow* any centralisation -- which I don't think  
 ever happens in practice!


  What about the Linux kernel? There's Linus's git repo, and lots of  
 repos maintained by others (e.g. Linux distros). The other distros are  
 not a superset of Linus's repo, they have their own branches with  
 various project-specific patches and backports. Git was written for  
 this specifically.


 Yes, but each distro has a trunk, in which all commits are ordered by  
 time. There's always an official version of every branch.


Ordered by time of what? Time of merging into the branch? That's not very  
useful, is it? They can't be ordered by time of authorship, for certain.

"Official" is technically meaningless in a DVCS, because no repository is  
holy by design (otherwise it wouldn't be really distributed). If the  
maintainer of a repository becomes MIA, anyone can take over without any  
problems.


 and (2) demand that cloning a repository be an entirely read-only  
 operation (so that the repository doesn't know how many times it has  
 been cloned)
 and (3) demand that the revision numbers behave exactly as they do in  
 svn.


  Then you're suggesting that the commit identifiers basically contain  
 the clone history?


 Yes, I think it could be done that way. Identifier would be composed of  
 clonenumber+commitnumber. Where it is the location of the original  
 change. Yes, there are difficulties with this scheme, but I think they  
 are the same challenges as for implementing merges on a centralised VCS  
 such as Subversion. I don't think there's anything insurmountable.


Then a clone of a clone of a clone of a clone needs four clone numbers,  
plus a revision number. It'd look something like 5:1:2:1:1056.

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
Jan 26 2011
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Vladimir Panteleev" <vladimir thecybershadow.net> wrote in message 
news:op.vpxqmbpftuzx1w cybershadow.mshome.net...

 On Wed, 26 Jan 2011 23:22:34 +0200, Don <nospam nospam.com> wrote:


 Vladimir Panteleev wrote:

 On Wed, 26 Jan 2011 06:33:35 +0200, Don <nospam nospam.com> wrote:


 I think this is a fallacy. It only applies if you
 (1) *completely disallow* any centralisation -- which I don't think 
 ever happens in practice!


  What about the Linux kernel? There's Linus's git repo, and lots of 
 repos maintained by others (e.g. Linux distros). The other distros are 
 not a superset of Linus's repo, they have their own branches with 
 various project-specific patches and backports. Git was written for 
 this specifically.


 Yes, but each distro has a trunk, in which all commits are ordered by 
 time. There's always an official version of every branch.


 Ordered by time of what? Time of merging into the branch? That's not very 
 useful, is it?


Why wouldn't it be? It didn't exist in that branch befoe, and then it was 
added to that branch.  "Feature X was introduced in Version 2.31 and didn't 
exist in the 1.x line. But then Feature X was backported to the 1.x line at 
time Y / revision Y, which was right after we fixed 1.x's bug A and right 
before we fixed 1.x's bug B". What's wrong with that? Seems perfectly 
sensible to me.
Jan 26 2011
prev sibling parent reply Don <nospam nospam.com> writes:
Vladimir Panteleev wrote:

 On Wed, 26 Jan 2011 23:22:34 +0200, Don <nospam nospam.com> wrote:
 

 Vladimir Panteleev wrote:

 On Wed, 26 Jan 2011 06:33:35 +0200, Don <nospam nospam.com> wrote:


 I think this is a fallacy. It only applies if you
 (1) *completely disallow* any centralisation -- which I don't think 
 ever happens in practice!


  What about the Linux kernel? There's Linus's git repo, and lots of 
 repos maintained by others (e.g. Linux distros). The other distros 
 are not a superset of Linus's repo, they have their own branches with 
 various project-specific patches and backports. Git was written for 
 this specifically.


 Yes, but each distro has a trunk, in which all commits are ordered by 
 time. There's always an official version of every branch.


 
 Ordered by time of what? Time of merging into the branch? That's not 
 very useful, is it? They can't be ordered by time of authorship, for 
 certain.
 
 "Official" is technically meaningless in a DVCS, because no repository 
 is holy by design (otherwise it wouldn't be really distributed).


Yes, in theory that's true. In practice, I don't believe it.
Just because you're using a DVCS doesn't mean you have no project 
organisation whatsoever. There's always going to be a repository that 
the release is made from.


 If the 
 maintainer of a repository becomes MIA, anyone can take over without any 
 problems.
 

 and (2) demand that cloning a repository be an entirely read-only 
 operation (so that the repository doesn't know how many times it has 
 been cloned)
 and (3) demand that the revision numbers behave exactly as they do 
 in svn.


  Then you're suggesting that the commit identifiers basically contain 
 the clone history?


 Yes, I think it could be done that way. Identifier would be composed 
 of clonenumber+commitnumber. Where it is the location of the original 
 change. Yes, there are difficulties with this scheme, but I think they 
 are the same challenges as for implementing merges on a centralised 
 VCS such as Subversion. I don't think there's anything insurmountable.


 
 Then a clone of a clone of a clone of a clone needs four clone numbers, 
 plus a revision number. It'd look something like 5:1:2:1:1056.


No. Just one repository number, and one revision number. You just need 
to be sensible in how the clone numbers are assigned. That's easy.
Basically every repository has a number of clone numbers it can assign.
Every clone gets a subset of that range. Dealing with the situation when 
the range has run out is a bit complicated, but quite doable, and there 
are steps you can take to make it a very rare occurence.

I'm not have almost zero interest in this stuff, so I won't say any 
more. I'm really just commenting that it's not difficult to envisage an 
algorithm which makes exposing a random hash unnecessary.
Jan 27 2011
next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thu, 27 Jan 2011 21:48:28 +0200, Don <nospam nospam.com> wrote:


 No. Just one repository number, and one revision number. You just need  
 to be sensible in how the clone numbers are assigned. That's easy.
 Basically every repository has a number of clone numbers it can assign.
 Every clone gets a subset of that range. Dealing with the situation when  
 the range has run out is a bit complicated, but quite doable, and there  
 are steps you can take to make it a very rare occurence.


Giving this some thought, I'm now confident that this is not possible. The  
assignment algorithm must take into account all variations of imaginable  
cases (cloning hierarchy up to a certain depth). We're talking about an  
algorithm must give a unique ID to each node in an implicit tree, not  
knowing about the state of the rest of the tree except the state of each  
new node's parent. The only sensible solutions will quickly generate  
humongous numbers for some or other common real-life scenarios.

I believe we're not still arguing that these numbers must also be useful  
beyond their terseness and uniqueness?

I think it's easier to just use the first 5 characters from Git's SHA-1  
hash.


 I'm not have almost zero interest in this stuff, so I won't say any  
 more. I'm really just commenting that it's not difficult to envisage an  
 algorithm which makes exposing a random hash unnecessary.


You're welcome to not reply.

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
Jan 28 2011
prev sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thu, 27 Jan 2011 21:48:28 +0200, Don <nospam nospam.com> wrote:


 Yes, in theory that's true. In practice, I don't believe it.
 Just because you're using a DVCS doesn't mean you have no project  
 organisation whatsoever. There's always going to be a repository that  
 the release is made from.


Git was written specifically to aid the development of the Linux kernel,  
which is perhaps the most obvious counter-example to what you're stating.  
In the context of a distribution, the "main repository" of the project is  
the distro's kernel repository, where distro-specific development is made  
and upstream patches are merged in. The same can be said about Android, a  
widely-forked project.

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
Jan 28 2011
prev sibling next sibling parent reply Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
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.)
Jan 25 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Lutger Blijdestijn" <lutger.blijdestijn gmail.com> wrote in message 
news:ihnh65$ak4$1 digitalmars.com...

 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"


This part is the whole crux of it:

"Revision numbers referring to changesets are very likely to be different in 
another copy of a repository."

Which is why I keep saying "plus which repository you're talking about". How 
is that ambinguous or problematic? People keep implying that it is ambiguous 
or problematic, but no one says "how" except when rehashing the strawman of 
pretending as if I had never said "plus which repository you're talking 
about".

...Plus which repository you're talking about.
...Plus which repository you're talking about.
...Plus which repository you're talking about.
.
.
.
.
...Plus which repository you're talking about.


 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.


Agreed. And something that incorporates both a sequential number and a 
sensible system of referring to a particular repository (some sort of URI, 
for instance) can be used as not only a unique identifier, but a unique 
identifier that's actually readable and means something.



 You can't expect other people to piece together how the
 revision number has come to be, that is extremely brittle.


They don't need to piece it together because you can just say...

...which repository you're talking about.
...which repository you're talking about.
...which repository you're talking about.
.
.
.
.
...which repository you're talking about.
.
.
.
.
.
Jan 25 2011
parent reply Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
Nick Sabalausky wrote:


...

 

 You can't expect other people to piece together how the
 revision number has come to be, that is extremely brittle.


 
 They don't need to piece it together because you can just say...
 
 ...which repository you're talking about.
 ...which repository you're talking about.
 ...which repository you're talking about.
 .
 .
 .
 .
 ...which repository you're talking about.
 .
 .
 .
 .
 .


ok ok ok ok ok I get it. I spend some quality time with google and have 
found this:

$ git describe --tags

phobos-2.046-664-g938e1cc


So phobos is at the 664th commit since 2.046


http://gitfu.wordpress.com/2008/05/25/git-describe-great-another-way-to-
refer-to-commits/
Jan 25 2011
parent "Nick Sabalausky" <a a.a> writes:
"Lutger Blijdestijn" <lutger.blijdestijn gmail.com> wrote in message 
news:ihnkgk$g8d$1 digitalmars.com...

 Nick Sabalausky wrote:


 ...

 You can't expect other people to piece together how the
 revision number has come to be, that is extremely brittle.


 They don't need to piece it together because you can just say...

 ...which repository you're talking about.
 ...which repository you're talking about.
 ...which repository you're talking about.
 .
 .
 .
 .
 ...which repository you're talking about.
 .
 .
 .
 .
 .


 ok ok ok ok ok I get it. I spend some quality time with google and have
 found this:

 $ git describe --tags

 phobos-2.046-664-g938e1cc


 So phobos is at the 664th commit since 2.046


 http://gitfu.wordpress.com/2008/05/25/git-describe-great-another-way-to-
 refer-to-commits/


Ahh, now *that's* nice. All it needs now (and maybe it already has it) is to 
allow something like "detailedtag{local:phobos-2.046-664}" in place of 
hashes or HEAD {7} and have it just figure out and use the hash by itself.
Jan 25 2011
prev sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
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/
Jan 25 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Robert Clipsham wrote:

 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


The tipping point for me was noticing that while many debated Hg vs git, nobody 
argued for SVN!
Jan 25 2011
parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 25/01/11 22:48, Walter Bright wrote:

 Robert Clipsham wrote:

 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


 The tipping point for me was noticing that while many debated Hg vs git,
 nobody argued for SVN!


You have much to learn young Padawan! May the force be with you.

-- 
Robert
http://octarineparrot.com/
Jan 25 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
Robert Clipsham wrote:

 You have much to learn young Padawan! May the source be with you.


                                                 ^^^^^^

Fixed that for you.
Jan 25 2011
prev sibling parent David Nadlinger <see klickverbot.at> writes:
On 1/25/11 11:28 PM, Robert Clipsham wrote:

 For all the nay-sayers to numbers in revisions - unless you're working
 on huge projects with lots of developers,[…]


Erm, no offense intended, but »lots« seems to be pretty much everything 
above a single one for me – as soon as you'll use Mercurial like an 
actual DVCS, revision numbers will inevitably differ among the various 
repository clones.

For a small D-related example, just compare the revision numbers in the 
main Bitbucket repo and Alexey's personal one – and guess what you'll 
see. And unfortunately, LDC isn't quite »huge«.

I was skeptical about not having revision numbers available back when I 
started to use Git as well, but I still have to encounter a single 
situation in my workflow where I wouldn't have to look up the SVN rev 
referring to a particular commit (when I have to search through the logs 
anyway, I don't care about whether I have to use the hash or a SVN-style 
rev anyway), but still couldn't use some relative notation, possibly in 
combination with local branches/tags…

David
Jan 25 2011
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 23 January 2011 21:00:21 David Wang wrote:

 Dear Walter,
 
 I went to the github and try to download the source, I found that
 the latest version on github is the old version.
 
 for example:
 
 druntime - Downloads: dmd-2.042
 Phobos -   Downloads: phobos-2.046
 DMD -      Downloads: dmd-2.046
 
 I think the actural latest version of D should be 2.051.
 
 Why github can not showing the 2.051 version(dmd, phobos,
 druntime, and so on.) ?


If you grab the source with git, it's the latest version. I don't know how the 
downloads stuff works though - but as you say, it doesn't have the latest 
version. It will likely take some time to sort out all of the kinks of the 
transition though. From the looks of it, very few of the dmd/druntime/Phobos 
devs have experience with github.

- Jonathan M Davis
Jan 23 2011
parent Jesse Phillips <jessekphillips+D gmail.com> writes:
Jonathan M Davis Wrote:


 If you grab the source with git, it's the latest version. I don't know how the 
 downloads stuff works though - but as you say, it doesn't have the latest 
 version. It will likely take some time to sort out all of the kinks of the 
 transition though. From the looks of it, very few of the dmd/druntime/Phobos 
 devs have experience with github.
 
 - Jonathan M Davis


It looks like the downloads are generated off the tags. And since the tags
aren't correct nor is the downloads.
Jan 24 2011
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-01-24 05:26, Walter Bright wrote:

 https://github.com/organizations/D-Programming-Language

 We're all learning how to use github, but by most accounts it seems to
 be the best available system for the diverse group of people who work on
 it.


Are we supposed to be able to access this repository? When I enter the 
address in the web browser it redirects to the github start page. If I 
try to clone it I get this error:

fatal: https://github.com/organizations/D-Programming-Language 
/info/refs not found: did you run git update-server-info on the server?

-- 
/Jacob Carlborg
Jan 24 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday 24 January 2011 01:29:33 Jacob Carlborg wrote:

 On 2011-01-24 05:26, Walter Bright wrote:

 https://github.com/organizations/D-Programming-Language
 
 We're all learning how to use github, but by most accounts it seems to
 be the best available system for the diverse group of people who work on
 it.


 
 Are we supposed to be able to access this repository? When I enter the
 address in the web browser it redirects to the github start page. If I
 try to clone it I get this error:
 
 fatal: https://github.com/organizations/D-Programming-Language
 /info/refs not found: did you run git update-server-info on the server?


That links to the "organization" D-Programming-Language on github.

https://github.com/D-Programming-Language is the link to the list of 
repositories. You'll need to go the individual repository for a project to find 
the URL to use to clone that repository.

- Jonathan M Davis
Jan 24 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-01-24 10:35, Jonathan M Davis wrote:

 On Monday 24 January 2011 01:29:33 Jacob Carlborg wrote:

 On 2011-01-24 05:26, Walter Bright wrote:

 https://github.com/organizations/D-Programming-Language

 We're all learning how to use github, but by most accounts it seems to
 be the best available system for the diverse group of people who work on
 it.


 Are we supposed to be able to access this repository? When I enter the
 address in the web browser it redirects to the github start page. If I
 try to clone it I get this error:

 fatal: https://github.com/organizations/D-Programming-Language
 /info/refs not found: did you run git update-server-info on the server?


 That links to the "organization" D-Programming-Language on github.

 https://github.com/D-Programming-Language is the link to the list of
 repositories. You'll need to go the individual repository for a project to find
 the URL to use to clone that repository.

 - Jonathan M Davis


Ahh, I see.

-- 
/Jacob Carlborg
Jan 24 2011
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-01-24 05:26, Walter Bright wrote:

 https://github.com/organizations/D-Programming-Language

 We're all learning how to use github, but by most accounts it seems to
 be the best available system for the diverse group of people who work on
 it.


BTW, what about the backend in the DMD repository. Is is ok now to just 
fork the repository?

-- 
/Jacob Carlborg
Jan 24 2011
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2011-01-24 07:52:24 -0500, Jacob Carlborg <doob me.com> said:


 On 2011-01-24 05:26, Walter Bright wrote:

 https://github.com/organizations/D-Programming-Language
 
 We're all learning how to use github, but by most accounts it seems to
 be the best available system for the diverse group of people who work on
 it.


 
 BTW, what about the backend in the DMD repository. Is is ok now to just 
 fork the repository?


There's a big inviting 'Fork' button for that at the top of each page 
which duplicates the repository in your own account (without any 
warning I might add). So whether it's okay or not, I'm pretty sure most 
people who do not closely read the license will assume it is. A Github 
free account is meant for 'open-source' projects after all.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Jan 24 2011