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

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

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
prev sibling next sibling parent Johannes Pfau <spam example.com> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

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
prev sibling next sibling parent reply Johannes Pfau <spam example.com> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

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

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 =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=



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


Depends what you thought I was saying . . .=20 =20
 AFAIK only in Darcs branch and repository is the same.

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

 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

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

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

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.

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
prev sibling next sibling 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 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 "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
prev sibling next sibling parent 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
prev sibling next sibling 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 next sibling parent "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
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=

 a DVCS repository *is* a distinct DVCS repository. So, yea, like I said, =

 have to specify "which repository". The "common dev" repository. The "mai=

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

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

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=

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

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

? 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'=



 not
 as if nobody's ever going to run into it.



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


 understatement.

frankly, such things *have* happened. Winning the lottery and getting hit=

 lighting are *extremely* rare, and yet there are a *lot* of people who ha=

 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=

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

 for what happens should such an event occur.

. 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 "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 next sibling 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 "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
prev sibling next sibling parent "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
prev sibling 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 "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
prev sibling next sibling parent "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
prev sibling 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 :

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 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 next sibling parent "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
prev sibling next sibling 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 next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2011-01-25 at 21:24 -0500, Nick Sabalausky wrote:
[ . . . ]
 Ulrick mentioned that history rewriting is "encouraged under some particu=

 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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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!

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.

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
prev sibling next sibling 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 "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
prev sibling next sibling 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=




 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=



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



 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=




 use
 your idea.

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



 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=



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



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



 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=


 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=

 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
parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Nick Sabalausky wrote:
 "Bill Baxter" <wbaxter gmail.com> wrote in message=20
 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 =

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

 it.=20
=20

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 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 Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 =


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


 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. --=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
prev sibling 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 next 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 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
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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.

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
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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
prev sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, 2011-01-29 at 09:49 -0500, foobar wrote:
[ . . . ]
 The conceptual difference described above seems to me more of an insignif=

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=

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

one repository contains other repositories.=20
 Also, while "git clone" indeed copies all the upstream branches, it's als=

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