threads / discuss / 2843

RE: new file leaked onto release branch

Subject: RE: new file leaked onto release branch

## tl;dr

4 messages between Dec 14, 2005 and Dec 15, 2005.

replies: 3people: 3as markdown or json

Johannes Schindelin· Dec 14, 2005, 23:34 UTC · re: Brown, Len · lore
Hi,
On Wed, 14 Dec 2005, Brown, Len wrote:
> >BTW, are 5165, 3410, 5452, 5571... topic branch names?
> 
> yes, the are bugzilla ids
So, it could have been
	git pull . 5165
which mistakes 5165 for a short SHA1?

Hth, Dscho

Junio C Hamano· Dec 15, 2005, 00:37 UTC · re: Johannes Schindelin · lore

Re: new file leaked onto release branch

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 5 quoted lines
> 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.

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

that short SHA1 is ambiguous. But a branch name immediately under .git/refs/heads takes precedence:

        $ git branch 5165 master
        $ git rev-parse 5165 master
        acd9b7b4e08a3f0f48afa922d8e371414cf2d3b2
        acd9b7b4e08a3f0f48afa922d8e371414cf2d3b2
And this makes it safer and unambiguous:
        $ git branch -d 5165
        Deleted branch 5165.
        $ git branch bug/5165 master
        $ git rev-parse bug/5165
        acd9b7b4e08a3f0f48afa922d8e371414cf2d3b2

We might want to detect collisions between SHA1 prefix and branch names, but I am not sure if it is worth it in practice.

Johannes Schindelin· Dec 15, 2005, 01:29 UTC · re: Junio C Hamano · lore

Re: new file leaked onto release branch

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

← back to recent threads