>>>>> "CSA" == C Scott Ananian <[EMAIL PROTECTED]> writes:

CSA> On Fri, 15 Apr 2005, Junio C Hamano wrote:
>> to yours is no problem for me.  Currently I see your HEAD is at
>> 461aef08823a18a6c69d472499ef5257f8c7f6c8, so I will generate a
>> set of patches against it.

CSA> Have you considered using an s/key-like system to make these hashes
CSA> more human-readable?  Using the S/Key translation (11-bit chunks map
CSA> to a 1-4
CSA> letter word), Linus' HEAD is at:
CSA> ...which is a little longer, but speaking of branch "wow-scan" (which
CSA> gives 22 bits of disambiguation) is probably less error-prone than
CSA> discussing branch '461...' (only 12 bits).

I understand monotone folks have the same issue and they let you
use unambiguous prefix string.  And why do you stop counting at
"461" in your example?  To my eyes, "461aef" in this particular
string stands out and is easily typable, which gives me 24 bits

But seriously I doubt the hex format is needed to be shown to
humans very often.  E-mail communications like this one being a
very special exception.  I do not expect for people to be
talking about "Hey, Junio's patch against 461aef... from Linus
is a total crap" like that.

The only reason I mentioned his then-HEAD by hex is because I do
not have a public archive for him to pull from, and I wanted to
make it easy for him to do:

 $ mkdir junk && cd junk && mkdir .git &&
   read-tree `cat-file commit 461aef... | sed -e 's/^tree //;q'`
 $ patch < ../stupid-patch-from-junio-01
 $ show-diff

(it might have been better if I used the tree ID for this purpose).

For Cogito users the hex format does not matter.  "git pull"
will get whatever HEAD recorded in the file on the sending end
and the end user does not even have to know about it.

CSA> This is obviously a cogito issue, rather than a git-fs thing.


To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to