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

[foo]

Nick Sabalausky Wrote:

> "Robert Clipsham" <robert at octarineparrot.com> wrote in message 
> news:ihnk80$fsf$1 at digitalmars.com...
> > On 25/01/11 22:28, Nick Sabalausky wrote:
> >> I don't understand why you think I'm claiming anything of the sort. I 
> >> never
> >> said anything like that. I keep saying over and over and over and over 
> >> and
> >> over and over and over....."changeset number **PLUS WHICH REPOSITORY (and
> >> maybe branch, depending how the given system chooses to work)**"
> >
> > Person A has a repository with one branch, 'default' and has made two 
> > commits. The current revision number is 1.
> > Person B clones the repository and creates a branch, 'ver2', and makes two 
> > commits. The revision number in his repository is now 3, it is still 1 in 
> > person A's.
> > Person A makes a commit, his revision 2. B switches back to the 'default' 
> > branch, and makes another commit.  His revision 4. A pulls from the 
> > default branch, now B's revision 4 == A's revision 3.
> >
> > It's very easy for the revision numbers to get out of sync like this.
> 
> Right, I already understood all of that. But consider the following scenario 
> (And I realize that neither Hg nor Git work exactly like this, but until 
> Lutger mentioned the extra details in "git describe --tags" it sounded like 
> Git was much further away from this than Hg is):
> 
> Adam starts a repository:
> 
>     dvcs://joes-fancy-dvcs-hosting.org/users/Adam/SuperApp
> 
> It's Adam's project, so that could be considered the main "official" repo. 
> Adam makes five commits in the default "default" branch. His current 
> revision is:
> 
>     dvcs://joes-fancy-dvcs-hosting.org/users/Adam/SuperApp/default/4
> 
> Behind the scenes, that revision is associated with an SHA-1 hash of 
> "df3a9...". This same revision, thus, could also be referred to as:
> 
>     dvcs://joes-fancy-dvcs-hosting.org/users/Adam/SuperApp/hashes/df3a9...
> 
> But usually that's only used behind-the-scenes. Adam never cares about it 
> and neither do any of the other SuperApp contributors. But the DVCS often 
> uses it internally. (Are the hashes normally assiciated with a specific 
> branch? If so, then just consider it "SuperApp/default/hashes/df3a9..." 
> instead of "SuperApp/hashes/df3a9...").
> 
> Now, along comes Bob who clones Adam's SuperApp repo. Bob's copy of the same 
> revision is:
> 
>     dvcs://joes-fancy-dvcs-hosting.org/users/Bob/SuperApp/default/4
> 
> Naturally, he also has the same hash as Adam:
> 
>     dvcs://joes-fancy-dvcs-hosting.org/users/Bob/SuperApp/hashes/df3a9...
> 
> Then Adam and Bob start making commits, updates, pushes, pulls, etc, and 
> their revision numbers get out-of-sync. Adam and Bob are talking on a 
> newsgroup, and Adam mentions a super-cool improvement he just committed:
> 
>     dvcs://joes-fancy-dvcs-hosting.org/users/Adam/SuperApp/default/81
> 
> Adam doesn't know this, but that just happens to have the hash "78ac1..." 
> and thus be AKA:
> 
>     dvcs://joes-fancy-dvcs-hosting.org/users/Adam/SuperApp/hashes/78ac1...
> 
> Bob wants Adam's new change, so he tells his DVCS to merge in:
> 
>     dvcs://joes-fancy-dvcs-hosting.org/users/Adam/SuperApp/default/81
> 
> No problem. Bob didn't ask his DVCS for "r81", he asked it for "Adam's r81". 
> This revision now becomes Bob's:
> 
>     dvcs://joes-fancy-dvcs-hosting.org/users/Bob/SuperApp/default/117
>     dvcs://joes-fancy-dvcs-hosting.org/users/Bob/SuperApp/hashes/78ac1...
> 
> Since Adam announced this on a NG, Carlos also saw it and grabbed the new 
> change:
> 
>     dvcs://carlos-coder.co.uk/SuperApp/default/94
>     dvcs://carlos-coder.co.uk/SuperApp/hashes/78ac1...
> 
> They all start to use it, but Bob discovers a critical problem with it. So 
> Bob tells the NG to avoid:
> 
>     dvcs://joes-fancy-dvcs-hosting.org/users/Adam/SuperApp/default/81
> 
> Or, Bob might have referred to it with his own revision instead (Maybe 
> Adam's account was temporarily down):
> 
>     dvcs://joes-fancy-dvcs-hosting.org/users/Bob/SuperApp/default/117
> 
> So Carlos tells his DVCS to revert that URI. To do this, Carlos's DVCS looks 
> up Adam's or Bob's URI and finds the associated hash: "78ac1...". Then it 
> looks at Carlos's own copy of the repo, sees the active branch is "default", 
> and finds the revision in "default" associated with the hash "78ac1...", 
> which is:
> 
>     dvcs://carlos-coder.co.uk/SuperApp/default/94
> 
> Which then gets reverted.
> 
> 
> 

This looks to me like an awful solution in search for a problem. 
The commit hash is the internal ID mainly used by git itself. If you want to communicate commits to other developers you have better means to do so. Let's emphasize that auto incremented numbers is NOT those means. 

commit have sha1 hashes Just like people have ID numbers to identity them (or the social security number in the US). That doesn't mean I would call you in conversation: "person#122345445" I'll call you by a HUMAN GIVEN NAME (e.g. "Nick").

If you want to refer to a git commit on the NG simply tag it with a meaningful name such as:
dvcs://carlos-coder.co.uk/SuperApp/FixedMemBugWithFeatureA

I'd like to add that git supports two kinds of tags, light-weight ones to just give a name to a commit like in the use-case above and annotated ones for when you want to tag a release. Such a tag will contain the release notes and can be optionally signed. 

Of course you can use what ever notation for your releases - you can use the PI number like TeX does if you so choose.