Re: new file leaked onto release branch

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Dec 15, 2005, 01:29 UTC
Message-ID: <Pine.LNX.4.63.0512150208190.9568@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <7v7ja7ures.fsf@assigned-by-dhcp.cox.net>

Hi,

On Wed, 14 Dec 2005, Junio C Hamano wrote:

Show 10 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > So, it could have been
> >
> > 	git pull . 5165
> >
> > which mistakes 5165 for a short SHA1?
> 
> I do not think git-pull would work on arbitrary SHA1
> expressions, so you should be safe.

D'oh. I wanted to write it short, but I guess that made it only more confusing. In reality, Len used "git merge", and that works quite well with short SHA1s.

However, I just verified (as you did also), that they do not take precedence over branch names (the relevant piece of code is in get_sha1_1: get_short_sha1() is called only if get_sha1_basic() fails).

Show 7 quoted lines

> Interestingly...
> 
>         $ git rev-parse 5165
>         error: short SHA1 5165 is ambiguous.
>         5165
> 
> that short SHA1 is ambiguous.

I don't want to be a PITA, but it could be ambiguous only since short time ago.

Show 6 quoted lines

> But a branch name immediately under .git/refs/heads takes precedence:
>
>         $ git branch 5165 master
>         $ git rev-parse 5165 master
>         acd9b7b4e08a3f0f48afa922d8e371414cf2d3b2
>         acd9b7b4e08a3f0f48afa922d8e371414cf2d3b2

There is an interesting side effect: If 5165 as a short SHA1 would be unique, and there is a tag *and* a branch named 5165, git-rev-parse would expand the short SHA1...

However, it still does not solve the original riddle.

Ciao, Dscho