digitalmars.D.announce - D Programming Language source (dmd, phobos, etc.) has moved to github
- Walter Bright (3/3) Jan 23 2011 https://github.com/organizations/D-Programming-Language
- David Wang (10/10) Jan 23 2011 Dear Walter,
- Walter Bright (2/17) Jan 23 2011 I think it is because the tags were never done properly on svn, either.
- Johannes Pfau (7/24) Jan 24 2011 It's still possible to add the tags (see
- Steven Schveighoffer (9/32) Jan 24 2011 All source is included in the compiler. It's simply a matter of doing a...
- Johannes Pfau (20/56) Jan 24 2011 OK, here are some revisions:
- J C Calvarese (11/43) Jan 24 2011 Someone might find this wiki page of use:
- Steven Schveighoffer (9/68) Jan 24 2011 That is probably a doc bug. When creating the 'next' version in the
- Nick Sabalausky (3/20) Jan 24 2011 Does Git really not have real revision/changeset numbers?
- Jonathan M Davis (13/40) Jan 24 2011 It's SHA1 hashes. And actually, considering how prevalent branching and ...
- Nick Sabalausky (6/54) Jan 24 2011 Not that I've actually used DVCSes much yet, but my understanding is tha...
- Jesse Phillips (6/10) Jan 24 2011 Here, how about a quote:
- Jonathan M Davis (11/69) Jan 24 2011 I don't know. I haven't used Hg. However, I have a hard time seeing how ...
- Trass3r (3/5) Jan 24 2011 Mercurial uses hashes.
- David Nadlinger (12/20) Jan 24 2011 Hg has no »real revision/changeset numbers« either – there is a
- Nick Sabalausky (21/44) Jan 24 2011 Even without really using DVCSes it always seemed clear to me that an
- Lutger Blijdestijn (5/39) Jan 25 2011 This covers most of it to see what's possible:
- Nick Sabalausky (18/60) Jan 25 2011 Ahh, that's not remotely what I was hoping it was. Everything is all
- Nick Sabalausky (5/72) Jan 25 2011 Additionally, Hg's approach provides a trivial way to disambiguate hash
- Vladimir Panteleev (16/32) Jan 25 2011 Not just what repository, but what clone of the repository! It's explain...
- Nick Sabalausky (28/59) Jan 25 2011 That's the same exact concept, isn't it? My understanding is that a clon...
- Robert Clipsham (21/25) Jan 25 2011 Person A has a repository with one branch, 'default' and has made two
- Nick Sabalausky (55/71) Jan 25 2011 Right, I already understood all of that. But consider the following scen...
- Ulrik Mikaelsson (51/75) Jan 25 2011 n
- Nick Sabalausky (4/5) Jan 25 2011 "History-rewrite" is new to me. Does that just mean branching off from a...
- Jonathan M Davis (4/12) Jan 25 2011 You can do stuff like re-order and squash commits. Look at the man page ...
- Nick Sabalausky (19/31) Jan 25 2011 Ok, I just took a look at it here:
- Jonathan M Davis (18/56) Jan 25 2011 I don't know how encouraged it is or isn't. The way I use it most often ...
- Vladimir Panteleev (20/29) Jan 25 2011 History rewriting in public repositories is very rare. It's a hassle for...
- Nick Sabalausky (5/31) Jan 25 2011 Ahh, I see. That does sound useful then. But that does mean that any
- Russel Winder (27/29) Jan 26 2011 lar=20
- Vladimir Panteleev (21/52) Jan 25 2011 OK, I see your point. However, I would avoid using such a way to refer t...
- Nick Sabalausky (10/18) Jan 25 2011 Well, normally there's at least *some* repository that's remotely
- Vladimir Panteleev (9/14) Jan 25 2011 Thus the question is - does Hg even allow you to (easily) inspect revisi...
- Nick Sabalausky (35/47) Jan 25 2011 Yes. Exhibits A, B and C:
- Andrej Mitrovic (10/11) Jan 25 2011 changeset: 0:08d729df85c9
- Kagamin (2/16) Jan 26 2011 LOL, this meaningless gibberish is usually called a unique identifier.
- David Wang (11/27) Jan 26 2011 And I use git to download the source from github.com for "druntime".
- Vladimir Panteleev (11/22) Jan 26 2011 The source code of druntime is under the src/core directory[1]. The .di ...
- Nick Sabalausky (5/23) Jan 26 2011 I don't care what it's called. *Both* of the above examples are obviousl...
- Vladimir Panteleev (8/9) Jan 26 2011 I think everyone's just annoyed how you're fiercely defending an idea th...
- Nick Sabalausky (13/20) Jan 26 2011 Terseness is not at all the only advantage. As I've said before, you can...
- Jonathan M Davis (11/37) Jan 26 2011 LOL. I think that part of what it comes down to is that you're making a ...
- Nick Sabalausky (5/45) Jan 26 2011 Heh, fair enough :)
- Bill Baxter (27/74) Jan 26 2011 Mercurial gives every revision two numbers:
- Nick Sabalausky (5/7) Jan 27 2011 Yea, and that's pretty much the original thing I was saying: It's nice t...
- Bill Baxter (9/19) Jan 27 2011 I think it's very handy for all the reasons you said. I don't think
- =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= (16/27) Jan 27 2011 that=20
- Russel Winder (17/29) Jan 28 2011 that
- Mafi (6/23) Jan 28 2011 I don't know Git but in Mercurial speech a branch is what you get when
- Leandro Lucarella (11/29) Jan 28 2011 WRONG about Git.
- Russel Winder (21/28) Jan 28 2011 Depends what you thought I was saying . . .=20
- =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= (17/39) Jan 29 2011 e
- Russel Winder (26/34) Jan 29 2011 Definitely, this is not at issue. The way Git and Mercurial store
- foobar (5/40) Jan 29 2011 The conceptual difference described above seems to me more of an insigni...
- Russel Winder (26/30) Jan 29 2011 icant minor implementation detail than anything else.=20
- Kagamin (3/29) Jan 27 2011 Well, I was talking more about the "gibberish" statement. I was surprise...
- Kagamin (2/16) Jan 26 2011 A little example: today I commited changeset 35912, and 35780 - 10 day a...
- Nick Sabalausky (7/27) Jan 26 2011 1. That's obviously a *lot* easier than 9f4e5ac4f0a3 and 13cf8da225ce
- Vladimir Panteleev (6/11) Jan 26 2011 None of these assertions hold in a DVCS repository. Merging in or rebasi...
- Nick Sabalausky (10/18) Jan 26 2011 I don't see how merging would cause a problem. A merge is a new commit, ...
- Vladimir Panteleev (10/36) Jan 26 2011 Yes, but the commit numbers lose any meaning beyond the order in which t...
- Nick Sabalausky (8/42) Jan 26 2011 It may not as meaningful as an SVN repo that never does any branching. B...
- Walter Bright (4/9) Jan 25 2011 A version number is fundamentally linear, and so will not work very well...
- Don (13/37) Jan 25 2011 I think this is a fallacy. It only applies if you
- Jonathan M Davis (11/49) Jan 25 2011 The main reason for the SHA1 is to verify that the repository hasn't bee...
- Vladimir Panteleev (11/19) Jan 26 2011 What about the Linux kernel? There's Linus's git repo, and lots of repos...
- Don (8/28) Jan 26 2011 Yes, but each distro has a trunk, in which all commits are ordered by
- Vladimir Panteleev (12/37) Jan 26 2011 Ordered by time of what? Time of merging into the branch? That's not ver...
- Nick Sabalausky (8/25) Jan 26 2011 Why wouldn't it be? It didn't exist in that branch befoe, and then it wa...
- Don (14/57) Jan 27 2011 Yes, in theory that's true. In practice, I don't believe it.
- Vladimir Panteleev (16/25) Jan 28 2011 Giving this some thought, I'm now confident that this is not possible. T...
- Vladimir Panteleev (10/14) Jan 28 2011 Git was written specifically to aid the development of the Linux kernel,...
- Lutger Blijdestijn (12/79) Jan 25 2011 I see, you want a convenient name for a particular commit, is that it? B...
- Nick Sabalausky (36/114) Jan 25 2011 This part is the whole crux of it:
- Lutger Blijdestijn (9/29) Jan 25 2011 ok ok ok ok ok I get it. I spend some quality time with google and have
- Nick Sabalausky (5/34) Jan 25 2011 Ahh, now *that's* nice. All it needs now (and maybe it already has it) i...
- Robert Clipsham (21/37) Jan 25 2011 This is the primary reason I use hg over git (that and I find it far
- Walter Bright (3/6) Jan 25 2011 The tipping point for me was noticing that while many debated Hg vs git,...
- Robert Clipsham (5/12) Jan 25 2011 You have much to learn young Padawan! May the force be with you.
- Walter Bright (3/4) Jan 25 2011 ^^^^^^
- David Nadlinger (16/18) Jan 25 2011 Erm, no offense intended, but »lots« seems to be pretty much everythin...
- Jonathan M Davis (7/22) Jan 23 2011 If you grab the source with git, it's the latest version. I don't know h...
- Jesse Phillips (2/9) Jan 24 2011 It looks like the downloads are generated off the tags. And since the ta...
- Jacob Carlborg (8/12) Jan 24 2011 Are we supposed to be able to access this repository? When I enter the
- Jonathan M Davis (6/19) Jan 24 2011 That links to the "organization" D-Programming-Language on github.
- Jacob Carlborg (4/23) Jan 24 2011 Ahh, I see.
- Jacob Carlborg (5/9) Jan 24 2011 BTW, what about the backend in the DMD repository. Is is ok now to just
- Michel Fortin (10/19) Jan 24 2011 There's a big inviting 'Fork' button for that at the top of each page
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
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
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
Walter Bright wrote:David Wang wrote: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 PfauDear 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.
Jan 24 2011
On Mon, 24 Jan 2011 09:00:21 -0500, Johannes Pfau <spam example.com> wrote:Walter Bright 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 (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... -SteveDavid Wang wrote: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?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 24 2011
Steven Schveighoffer wrote:On Mon, 24 Jan 2011 09:00:21 -0500, Johannes Pfau <spam example.com> wrote: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 PfauWalter Bright 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... -SteveDavid Wang wrote: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?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 24 2011
== 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:...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. jcc7All 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... -SteveOK, 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.
Jan 24 2011
On Mon, 24 Jan 2011 10:34:18 -0500, Johannes Pfau <spam example.com> wrote:Steven Schveighoffer wrote: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.On Mon, 24 Jan 2011 09:00:21 -0500, Johannes Pfau <spam example.com> wrote: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.Walter Bright 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 (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... -SteveDavid Wang wrote: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?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.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
"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
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...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 DavisOK, 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
"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: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."Johannes Pfau" <spam example.com> wrote in message news:20110124163418.3880a154 jpf-Satellite-A100...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.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
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
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...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 DavisOn Monday 24 January 2011 13:04:27 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."Johannes Pfau" <spam example.com> wrote in message news:20110124163418.3880a154 jpf-Satellite-A100...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.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
I don't know. I haven't used Hg. However, I have a hard time seeing how you could have revision numbers like subversion doesMercurial uses hashes. For convenience it *additionally* provides consecutive numbers which are to be used in your own *local repo only*.
Jan 24 2011
On 1/24/11 10:20 PM, Nick Sabalausky wrote: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. DavidNot 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.Does Git really not have real revision/changeset numbers?[…]
Jan 24 2011
"David Nadlinger" <see klickverbot.at> wrote in message news:ihkub8$1ia4$1 digitalmars.com...On 1/24/11 10:20 PM, Nick Sabalausky wrote: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?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).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.Does Git really not have real revision/changeset numbers?[.]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
Nick Sabalausky wrote:"David Nadlinger" <see klickverbot.at> wrote in message news:ihkub8$1ia4$1 digitalmars.com...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"On 1/24/11 10:20 PM, Nick Sabalausky wrote: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?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).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.Does Git really not have real revision/changeset numbers?[.]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?
Jan 25 2011
"Lutger Blijdestijn" <lutger.blijdestijn gmail.com> wrote in message news:ihn21d$2esd$1 digitalmars.com...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.)"David Nadlinger" <see klickverbot.at> wrote in message news:ihkub8$1ia4$1 digitalmars.com...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"On 1/24/11 10:20 PM, Nick Sabalausky wrote: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?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).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.Does Git really not have real revision/changeset numbers?[.]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?
Jan 25 2011
"Nick Sabalausky" <a a.a> wrote in message news:ihne76$4cp$1 digitalmars.com..."Lutger Blijdestijn" <lutger.blijdestijn gmail.com> wrote in message news:ihn21d$2esd$1 digitalmars.com...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.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.)"David Nadlinger" <see klickverbot.at> wrote in message news:ihkub8$1ia4$1 digitalmars.com...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"On 1/24/11 10:20 PM, Nick Sabalausky wrote: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?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).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.Does Git really not have real revision/changeset numbers?[.]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?
Jan 25 2011
On Tue, 25 Jan 2011 23:08:13 +0200, Nick Sabalausky <a a.a> wrote:Browsing through http://hginit.com/index.html, it looks like with Hg, everything works just as well as with SVN, the only difference being that you need to remember to specify which repository you're talking about whenever you give a number.Not just what repository, but what clone of the repository! It's explained in http://hginit.com/05.html. The number only makes sense for the clone of the repository you're working on right now - basically you can't tell that number to anyone, because it might mean something entirely different for them.Obviously I'm not saying "DMD should have gone Hg", I'm just kinda shocked by how horrid Git's approach is for referring to changesets. (Personally, that alone would be enough to get me to use Hg instead of Git for my own projects. Heck, I've become pretty much sold on the idea of DVCS, but because of this I think I'd actually sooner use SVN for a new project than Git.)I think you need to take some time and think about it. It's impossible to use a global incrementing revision number with any DVCS! In fact, I dare to think that Hg having revision numbers is a stupid mistake that tries to make SVN users comfy, but will only lead to confusion and angst when people try to refer to revisions by their "number".Additionally, Hg's approach provides a trivial way to disambiguate hash collisions. I know that Git book brushes it off as "very rare", but it's not as if nobody's ever going to run into it.Um, what method is that? Also, saying that SHA-1 hash collisions are "very rare" is a bit of an understatement. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 25 2011
"Vladimir Panteleev" <vladimir thecybershadow.net> wrote in message news:op.vpvv5sn8tuzx1w cybershadow.mshome.net...On Tue, 25 Jan 2011 23:08:13 +0200, Nick Sabalausky <a a.a> wrote: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.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.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.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)**"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".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.Version number together with being specific about which repository.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.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
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
"Robert Clipsham" <robert octarineparrot.com> wrote in message news:ihnk80$fsf$1 digitalmars.com...On 25/01/11 22:28, Nick Sabalausky wrote: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.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.
Jan 25 2011
That's the same exact concept, isn't it? My understanding is that a clone=ofa DVCS repository *is* a distinct DVCS repository. So, yea, like I said, =youhave to specify "which repository". The "common dev" repository. The "mai=nstable repository". The "only shared repository this small project actual=lyhas". Or "Bob's repository" for what little that would be worth.Mostly a side-note, but in many DVCS:es (git in particular, but both bzr and hg has it too), history rewriting is allowed, even encouraged under some particular circumstances. In that case, the SHA-1 revision will CERTAINLY change, while even repo+number is not very reliable. Some kernel-branches are maintained like that, for example. Furthermore, a related hg-anecdote; Personally, for my work-flow I often use history-rewriting to jump around, amending patches, rebasing them before pushing, etc. I've become very accustomed to it, and find it extremely useful. When trying out hg a while back (to make patches for LDC IIRC), the attempted linear-history was actually one of my biggest disappointments. I quickly ended up in a situation where all my patches looked like a zig-zag-stacked hodgepodge of stuff, many of them not intended to even keep in the repo. When reading the docs about it, the only useful suggestion I found was to create a new repo, and cherry-pick what I wanted from the old. It's possible this were mostly due to my inexperience with Hg, but it strengthened my conviction that the unrealistic linear-numbers of a non-linear history are really just shoe-horning in something for newbie-comfort, but quite off as a model. For me, It is the deal-breaker for hg.I don't understand why you think I'm claiming anything of the sort. I nev=ersaid anything like that. I keep saying over and over and over and over an=dover and over and over....."changeset number **PLUS WHICH REPOSITORY (and maybe branch, depending how the given system chooses to work)**"How should you linearly number the two chains A > B > C and A > D > C ? Is it A, B, D, C or A, D, B, C? Should they be inter-vowen by commit-time, or what?sAdditionally, Hg's approach provides a trivial way to disambiguate hash collisions. I know that Git book brushes it off as "very rare", but it'=Again, version-number + repo is not 100% when history-rewrite is possible.Version number together with being specific about which repository.not as if nobody's ever going to run into it.Um, what method is that?f anAlso, saying that SHA-1 hash collisions are "very =C2=A0rare" is a bit o=byunderstatement.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=lighting are *extremely* rare, and yet there are a *lot* of people who ha=vehad 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=necrashes and major earthquakes are extremely rare, but they sure as hell p=lanfor what happens should such an event occur.Getting hit by lightning isn't really on the same scale as SHA-1 collisions= . According to Wolfram Alpha, the odds of being struck by lightning in a given year is one in 750000. If I've understood things roughly right, (probabilities aren't my strong side) the best possible attack for SHA-1 requires 2^52 attempts (Note: intentional attack, pure random chance is likely MUCH higher). That means that, given a very big project of 1 million commits (2^20, by comparison Linux is at 232k atm), the chance of intentionally hitting a collision is 1 in 2^32 =3D 4billion. Suffice to say, comparatively there might be a prospering market for current-insulating clothing. I guess, when every household on earth are running it's own kernel-project, git might have to upgrade to SHA-512. (Hg too, btw. I think the REAL, internal revision-id:s for HG is sha-1 too, aren't they?)
Jan 25 2011
"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
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...You can do stuff like re-order and squash commits. Look at the man page for git- rebase. - Jonathan M DavisAgain, 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
"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: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?"Ulrik Mikaelsson" <ulrik.mikaelsson gmail.com> wrote in message news:mailman.949.1295999711.4748.digitalmars-d-announce puremagic.com...You can do stuff like re-order and squash commits. Look at the man page for git- rebase.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
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...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 DavisOn Tuesday, January 25, 2011 16:50:03 Nick Sabalausky wrote: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?"Ulrik Mikaelsson" <ulrik.mikaelsson gmail.com> wrote in message news:mailman.949.1295999711.4748.digitalmars-d-announce puremagic.com...You can do stuff like re-order and squash commits. Look at the man page for git- rebase.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
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
"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: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.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.
Jan 25 2011
On Tue, 2011-01-25 at 21:24 -0500, Nick Sabalausky wrote: [ . . . ]Ulrick mentioned that history rewriting is "encouraged under some particu=lar=20circumstances". 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
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.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.netAlso, 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
"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: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.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.
Jan 25 2011
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
"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: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).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?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
As far as I can tell hg stores both a commit number and a hash, e.g.:D:\dev\projects\project>hg log -r :changeset: 0:08d729df85c9 user: Andrej Mitrovic <andrej.mitrovich gmail.com> date: Fri Dec 22 00:07:02 2010 +0200 summary: bla bla changeset: 1:61cfebefee15 user: Andrej Mitrovic <andrej.mitrovich gmail.com> date: Fri Dec 24 21:42:45 2010 +0100 summary: bla bla I don't know the details, I've just started using hg recently.
Jan 25 2011
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
== Repost the article of Kagamin (spam here.lot) == Posted at 2011/01/26 07:31 to digitalmars.D.announceNick 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
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
"Kagamin" <spam here.lot> wrote in message news:ihp46m$b3$1 digitalmars.com...Nick Sabalausky Wrote: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?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
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
"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: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.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.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
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...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 DavisOn Wed, 26 Jan 2011 22:46:44 +0200, Nick Sabalausky <a a.a> wrote: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.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.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
"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:Heh, fair enough :)"Vladimir Panteleev" <vladimir thecybershadow.net> wrote in message news:op.vpxphnlmtuzx1w cybershadow.mshome.net...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.On Wed, 26 Jan 2011 22:46:44 +0200, Nick Sabalausky <a a.a> wrote: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.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.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!!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
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...aOn 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=anthat 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=yreason about them, compare them, and get a general idea of "where" the=n'tare 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=ownuse your idea.What? Are you actually trying to claim that defending/promoting one's =entidea 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=befrom Git's world-view. If Git does something one way then that *must* =ingthe best way, right? Anything else is obviously just heresy, right? Br=ingHeh, fair enough :)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 increas=ngones 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
"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
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...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. --bbMercurial 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
Nick Sabalausky wrote:"Bill Baxter" <wbaxter gmail.com> wrote in message=20 news:mailman.977.1296083661.4748.digitalmars-d-announce puremagic.com..==2Ethat=20Mercurial gives every revision two numbers: Is that the kind of thing you're wanting?=20 Yea, and that's pretty much the original thing I was saying: It's nice =Hg seems to have it, but Git doesn't appear to be particularly interest=ed in=20it.=20 =20Of course, Git does not have it! Svn has it so it *must* be a bad idea ;) Jerome PS: FWIW, I agree with you. Plus, there is another use case where sequential number are very useful: each time you want to operate on a past revision in your own repository (e.g "hg up n" or "hg diff -r n"), it is much easier to designate that revision with a sequential number than with the hash. --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jan 27 2011
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:[ . . . ]thatYea, and that's pretty much the original thing I was saying: It's nice =ed inHg seems to have it, but Git doesn't appear to be particularly interest=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_winderit.=20 I think it's very handy for all the reasons you said. I don't think I've every had to use a big hex string when dealing with mercurial. Maybe once or twice max. Most of the stuff you do with repo history as an individual developer is all about the local copy of the tree on your system. Globally unique identifiers aren't needed for that. It looks like Bzr does something similar. Not sure why Git hasn't gotten this particular nicety.
Jan 28 2011
Am 28.01.2011 12:30, schrieb Russel Winder:On Thu, 2011-01-27 at 13:33 -0800, Bill Baxter wrote:I don't know Git but in Mercurial speech a branch is what you get when using the 'hg branch' command. It's like a tag but a commit can only belongs to exactly one branch ('default' is the default branch). All commits to all branches are put together in one repository. MafiOn Thu, Jan 27, 2011 at 1:13 PM, Nick Sabalausky<a a.a> wrote:[ . . . ]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.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.
Jan 28 2011
Russel Winder, el 28 de enero a las 11:30 me escribiste:On Thu, 2011-01-27 at 13:33 -0800, Bill Baxter wrote: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 enoughOn Thu, Jan 27, 2011 at 1:13 PM, Nick Sabalausky <a a.a> wrote:[ . . . ]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.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.
Jan 28 2011
On Fri, 2011-01-28 at 12:43 -0300, Leandro Lucarella wrote:Russel Winder, el 28 de enero a las 11:30 me escribiste:[ . . . ]Depends what you thought I was saying . . .=20Bazaar does indeed have revision numbers per branch. Note that branch and repository is a different concept in Bazaar, unlike Git and Mercurial where they are fundamentally the same.=20 WRONG about Git.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
Russel Winder wrote:On Fri, 2011-01-28 at 12:43 -0300, Leandro Lucarella wrote:hRussel Winder, el 28 de enero a las 11:30 me escribiste:[ . . . ]Bazaar does indeed have revision numbers per branch. Note that branc=e=20 Depends what you thought I was saying . . .=20 =20and 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.=20 . . . I think you misunderstood what I meant by my statement. =20 What I was trying to say was that Git and Mercurial have effectively th=same ideas of repository and branch (at least from a surface usage perspective -- there are significant differences if you delve deeply). Bazaar has a very different idea of what branch and repository are. So=in this respect Git and Mercurial are in the same equivalence class and=Bazaar is in a different one. I have no idea where Darcs would sit, I have never used it beyond trying to compile Haskell this time last year==2E=20In Mercurial (and AFAIK Git), branches and repositories are completely different concepts. A repository is a folder on your hard drive. A branch is a history line inside a repository so it's not that different from Bazaar. The only difference I see is that Bazaar allows you to clone a single branch (i.e to create a repository that will only contain that single branch) whereas a clone of a Mercurial repository will always contain all the branches that the parent had (don't know about Git). Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jan 29 2011
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 notDefinitely, 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
Russel Winder Wrote:On Sat, 2011-01-29 at 11:18 +0100, "Jérôme M. Berger" wrote: [ . . . ]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.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 notDefinitely, 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
Jan 29 2011
On Sat, 2011-01-29 at 09:49 -0500, foobar wrote: [ . . . ]The conceptual difference described above seems to me more of an insignif=icant minor implementation detail than anything else.=20 Not at all. But I am really not going to argue the point any further. D has chosen Git, which is fine.A git repository can contain one or more branches and you obviously can h=ave more than one repository so this boils down to your personal workflow p= references.=20In other words you can have multiple repositories for the same project an=d just use them as branches. Git also provides sub-module support such that= one repository contains other repositories.=20Also, while "git clone" indeed copies all the upstream branches, it's als=o simple to track just a specific branch (or any subset) of the upstream br= anches. It's just a matter of doing a git init with the relevant options in= stead of relying on the default git clone behavior.=20 Yes, but this (except tracking branches) applies to Mercurial as well. And mostly to Bazaar. However note the above. Tracking branches are probably the single most useful thing in Git compared to Mercurial and Bazaar. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 29 2011
Nick Sabalausky Wrote:"Kagamin" <spam here.lot> wrote in message news:ihp46m$b3$1 digitalmars.com...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?Nick Sabalausky Wrote: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?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 27 2011
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
"Kagamin" <spam here.lot> wrote in message news:ihpjji$115f$1 digitalmars.com...Nick Sabalausky Wrote: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.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
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
"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: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).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.
Jan 26 2011
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...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.On Wed, 26 Jan 2011 22:43:11 +0200, Nick Sabalausky <a a.a> wrote: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.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.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
"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:It may not as meaningful as an SVN repo that never does any branching. But it's still much more meaningful than a hash."Vladimir Panteleev" <vladimir thecybershadow.net> wrote in message news:op.vpxo9jz4tuzx1w cybershadow.mshome.net...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.On Wed, 26 Jan 2011 22:43:11 +0200, Nick Sabalausky <a a.a> wrote: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.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 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.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.
Jan 26 2011
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
Vladimir Panteleev wrote:On Tue, 25 Jan 2011 23:08:13 +0200, Nick Sabalausky <a a.a> 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! 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.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!
Jan 25 2011
On Tuesday 25 January 2011 20:33:35 Don wrote:Vladimir Panteleev wrote: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 DavisOn Tue, 25 Jan 2011 23:08:13 +0200, Nick Sabalausky <a a.a> 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! 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.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!
Jan 25 2011
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
Vladimir Panteleev wrote:On Wed, 26 Jan 2011 06:33:35 +0200, Don <nospam nospam.com> wrote:Yes, but each distro has a trunk, in which all commits are ordered by time. There's always an official version of every branch.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, 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.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?
Jan 26 2011
On Wed, 26 Jan 2011 23:22:34 +0200, Don <nospam nospam.com> wrote:Vladimir Panteleev wrote: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.On Wed, 26 Jan 2011 06:33:35 +0200, Don <nospam nospam.com> wrote:Yes, but each distro has a trunk, in which all commits are ordered by time. There's always an official version of every branch.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.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.netYes, 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.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?
Jan 26 2011
"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: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.Vladimir Panteleev wrote:Ordered by time of what? Time of merging into the branch? That's not very useful, is it?On Wed, 26 Jan 2011 06:33:35 +0200, Don <nospam nospam.com> wrote:Yes, but each distro has a trunk, in which all commits are ordered by time. There's always an official version of every branch.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.
Jan 26 2011
Vladimir Panteleev wrote:On Wed, 26 Jan 2011 23:22:34 +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.Vladimir Panteleev wrote: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).On Wed, 26 Jan 2011 06:33:35 +0200, Don <nospam nospam.com> wrote:Yes, but each distro has a trunk, in which all commits are ordered by time. There's always an official version of every branch.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.If the maintainer of a repository becomes MIA, anyone can take over without any problems.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.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.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.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?
Jan 27 2011
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
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
Nick Sabalausky wrote:"Lutger Blijdestijn" <lutger.blijdestijn gmail.com> wrote in message news:ihn21d$2esd$1 digitalmars.com...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.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."David Nadlinger" <see klickverbot.at> wrote in message news:ihkub8$1ia4$1 digitalmars.com...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"On 1/24/11 10:20 PM, Nick Sabalausky wrote: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?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).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.Does Git really not have real revision/changeset numbers?[.]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?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
"Lutger Blijdestijn" <lutger.blijdestijn gmail.com> wrote in message news:ihnh65$ak4$1 digitalmars.com...Nick Sabalausky wrote: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."Lutger Blijdestijn" <lutger.blijdestijn gmail.com> wrote in message news:ihn21d$2esd$1 digitalmars.com...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"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."David Nadlinger" <see klickverbot.at> wrote in message news:ihkub8$1ia4$1 digitalmars.com...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"On 1/24/11 10:20 PM, Nick Sabalausky wrote: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?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).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.Does Git really not have real revision/changeset numbers?[.]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?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
Nick Sabalausky wrote: ...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/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
"Lutger Blijdestijn" <lutger.blijdestijn gmail.com> wrote in message news:ihnkgk$g8d$1 digitalmars.com...Nick Sabalausky wrote: ...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.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/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
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
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 :DThe tipping point for me was noticing that while many debated Hg vs git, nobody argued for SVN!
Jan 25 2011
On 25/01/11 22:48, Walter Bright wrote:Robert Clipsham wrote:You have much to learn young Padawan! May the force be with you. -- Robert http://octarineparrot.com/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 :DThe tipping point for me was noticing that while many debated Hg vs git, nobody argued for SVN!
Jan 25 2011
Robert Clipsham wrote:You have much to learn young Padawan! May the source be with you.^^^^^^ Fixed that for you.
Jan 25 2011
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
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
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 DavisIt looks like the downloads are generated off the tags. And since the tags aren't correct nor is the downloads.
Jan 24 2011
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
On Monday 24 January 2011 01:29:33 Jacob Carlborg wrote:On 2011-01-24 05:26, Walter Bright wrote: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 Davishttps://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?
Jan 24 2011
On 2011-01-24 10:35, Jonathan M Davis wrote:On Monday 24 January 2011 01:29:33 Jacob Carlborg wrote:Ahh, I see. -- /Jacob CarlborgOn 2011-01-24 05:26, Walter Bright wrote: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 Davishttps://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?
Jan 24 2011
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
On 2011-01-24 07:52:24 -0500, Jacob Carlborg <doob me.com> said:On 2011-01-24 05:26, Walter Bright wrote: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/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?
Jan 24 2011