Re: Referring to revisions in the git future.

[Barry Warsaw <barry@python.org>]

[-- Attachment #1: Type: text/plain, Size: 1674 bytes --]

On Oct 28, 2014, at 08:49 PM, Eric S. Raymond wrote:

>Git does not have such a mapping.  This is not the git designers being
>perverse; all other DVCSes have the same issue. A true DVCS is
>designed for distributed operation in which there is no privileged node
>to hand out the monotonically-increasing IDs.

This is certainly true in theory, but in practice you almost always have
sufficient context for monotonically increasing revision numbers[*] to make
sense.

For example, bzr has both revision hashes for unique reference, but it also
has human friendly revision numbers, which will generally be completely fine
to use in practice.  When used like this, the context is almost always for the
"trunk" branch in the "master" repository.

Yes, of course dvcs, democracy, and all, but I claim that most projects have a
canonical place for their source code.  If you ask their project leaders "how
do I get your code", they will answer with the url to this canonical location.
Thus, "your bug is fixed in r19801" has implied context for this url, and the
master, trunk, line-of-development (or whatever you call it) branch.

git really doesn't acknowledge this common development workflow, so it's
understandable that it doesn't in anyway support human readable revision ids.

It's also true that in e.g. bzr, if you really had to refer to a unique
revision id, you can use the hash.  It's just that in polite conversation
<wink>, it's rarely needed.

Cheers,
-Barry

[*] Although it's true that some bzr merge operations can "mess with" those
numbers, it's generally bad practice to use merge in such a way as to cause
this to happen.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]