# RE: new file leaked onto release branch 4 messages from 2005-12-14 to 2005-12-15. Participants: Brown, Len, Johannes Schindelin, Junio C Hamano. Thread: https://gitlist.dev/t/2843 ## Brown, Len, 2005-12-14 22:48 Subject: RE: new file leaked onto release branch Message-ID: URL: https://gitlist.dev/e/F7DC2337C7631D4386A2DF6E8FB22B30056B8748%40hdsmsx401.amr.corp.intel.com ``` >BTW, are 5165, 3410, 5452, 5571... topic branch names? yes, the are bugzilla ids ``` ## Johannes Schindelin, 2005-12-14 23:34 Subject: RE: new file leaked onto release branch Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0512150034120.8992%40wbgn013.biozentrum.uni-wuerzburg.de In-Reply-To: ``` 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, 2005-12-15 00:37 Subject: Re: new file leaked onto release branch Message-ID: <7v7ja7ures.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v7ja7ures.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` 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. 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, 2005-12-15 01:29 Subject: Re: new file leaked onto release branch Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0512150208190.9568%40wbgn013.biozentrum.uni-wuerzburg.de 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 ```