[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Referring to revisions in the git future.

From: Barry Warsaw
Subject: Re: Referring to revisions in the git future.
Date: Wed, 29 Oct 2014 10:52:02 -0400

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

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.


[*] 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: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]