From: Johannes Schindelin Date: Thu, 15 Dec 2005 01:29:20 GMT Subject: Re: new file leaked onto release branch Message-ID: In-Reply-To: <7v7ja7ures.fsf@assigned-by-dhcp.cox.net> Hi, On Wed, 14 Dec 2005, Junio C Hamano wrote: > Johannes Schindelin 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). > 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. > 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