# Corruption of branch? 10 messages from 2015-12-14 to 2015-12-14. Participants: Thomas Nyberg, Stefan Beller, David Turner, Dennis Kaarsemaker, Junio C Hamano. Thread: https://gitlist.dev/t/40993 ## Thomas Nyberg, 2015-12-14 17:40 Subject: Corruption of branch? Message-ID: <566EFF11.6010600@gmail.com> URL: https://gitlist.dev/e/566EFF11.6010600%40gmail.com ``` Hello, I have a repository (which I unfortunately cannot provide access to) which is having some odd things happening with one (and only one) of its branches. This workflow repeats the issue (here `bad_branch` is one of the remotes branches; i.e. `origin/bad_branch`): (1) clone the repository (2) git checkout `bad_branch` Basically nothing happens. Nothing is printed and I stay on the master branch. I also checked $? and there is no error code that is set. If I choose any of other branches, it correctly creates a local branch, sets it to track the remote and then switches to the local branch. It seems like there could be some sort of weird bug in the checkout or possibly somehow some corruption in the actual object tree. From my vantage point, however, the data appears totally fine. For example, in `.git/packed-refs` everything appears normal and if I explicitly checkout the commit IDs directly (i.e. just copy the commit corresponding to refs/remotes/origin/bad_branch and checkout $commit) it checks out fine. If I do this with the bad_branch I get a detached HEAD as expected and git log lists the commits that it should. This seems a bit odd to me. There's certainly some sort of error somewhere, but it's passing silently. I'm not really sure how to debug this and it's too bad I can't actually link the actual repository. I presume if I have the time I could try compiling git from source and seeing if it still shows up. I tested it on the following two versions of git get the same error: * 1.9.1 (installed as a package from Linux Mint 17.2 Rafaela) * 2.1.4 (installed as a package from Debian Jessie 8.2) Also I should note that the original repository is hosted on Github. Thanks for any help. Hopefully the fact that I can't provide enough information for others to reproduce the issue isn't too large a bother... Cheers, Thomas Nyberg ``` ## Stefan Beller, 2015-12-14 17:51 Subject: Re: Corruption of branch? Message-ID: URL: https://gitlist.dev/e/CAGZ79kaUw8Hb_7hdAUbvmnmXvm3a-77j5t3zeyQ-7BqwPCSp%2BA%40mail.gmail.com In-Reply-To: <566EFF11.6010600@gmail.com> ``` On Mon, Dec 14, 2015 at 9:40 AM, Thomas Nyberg wrote: > Hello, > > I have a repository (which I unfortunately cannot provide access to) which > is having some odd things happening with one (and only one) of its branches. > This workflow repeats the issue (here `bad_branch` is one of the remotes > branches; i.e. `origin/bad_branch`): > > (1) clone the repository > (2) git checkout `bad_branch` > > Basically nothing happens. Nothing is printed and I stay on the master > branch. I also checked $? and there is no error code that is set. If I > choose any of other branches, it correctly creates a local branch, sets it > to track the remote and then switches to the local branch. Does that branch have a funny name? (i.e. is it ASCII only? Or is it also utf8 characters? Does it have some special characters in it like points, colons, question marks etc) Does it happen only with a single sha1 or can you apply commits on top of that branch and the error condition persists? > > It seems like there could be some sort of weird bug in the checkout or > possibly somehow some corruption in the actual object tree. From my vantage > point, however, the data appears totally fine. For example, in > `.git/packed-refs` everything appears normal and if I explicitly checkout > the commit IDs directly (i.e. just copy the commit corresponding to > refs/remotes/origin/bad_branch and checkout $commit) it checks out fine. If > I do this with the bad_branch I get a detached HEAD as expected and git log > lists the commits that it should. > > This seems a bit odd to me. There's certainly some sort of error somewhere, > but it's passing silently. I'm not really sure how to debug this and it's > too bad I can't actually link the actual repository. I presume if I have the > time I could try compiling git from source and seeing if it still shows up. > I tested it on the following two versions of git get the same error: > > * 1.9.1 (installed as a package from Linux Mint 17.2 Rafaela) > * 2.1.4 (installed as a package from Debian Jessie 8.2) The refs handling code is in flux at the moment. (starting mid of last year actually) I cc'd people who did work recently on the file refs.c So I think trying with a new version of Git would be a valuable datapoint! > > Also I should note that the original repository is hosted on Github. > > Thanks for any help. Hopefully the fact that I can't provide enough > information for others to reproduce the issue isn't too large a bother... > > Cheers, > Thomas Nyberg > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ``` ## Thomas Nyberg, 2015-12-14 18:08 Subject: Re: Corruption of branch? Message-ID: <566F05B2.8080403@gmail.com> URL: https://gitlist.dev/e/566F05B2.8080403%40gmail.com In-Reply-To: ``` Hi Stefan thanks for much for the response! So I compiled release version 2.6.4 as well as the current master branch on the git git repository (2.7.0.rc0.20.g4b9ab0e) and the problem persists on both. To answer your questions, there are no weird characters. The name of the bad_branch is "frus". There is another branch called "frus_body_cleaning" that is totally fine. As to whether the error continues after commits, the answer is no which is good. I.e. if I run `git checkout -b frus origin/frus` that works fine. I then decided to checkout a new branch (so as to not mess with the original branch and possibly turning this into a Heisenbug) and add a test commit which I pushed upstream. I then recloned the repository and was able to checkout this new branch just fine, but I still couldn't check out the original frus branch using the simplified command. So of course on the practical side, I have a fix which is to just use `git checkout -b frus origin/frus` (apparently only this one time) and then be on my merry way (in fact I had only just broken myself of the habit typing it this older way after many versions of the newer simpler syntax), but it seems like it could be good to sort out what's going on here... Thanks again for the response! Cheers, Thomas On 12/14/2015 12:51 PM, Stefan Beller wrote: > On Mon, Dec 14, 2015 at 9:40 AM, Thomas Nyberg wrote: >> Hello, >> >> I have a repository (which I unfortunately cannot provide access to) which >> is having some odd things happening with one (and only one) of its branches. >> This workflow repeats the issue (here `bad_branch` is one of the remotes >> branches; i.e. `origin/bad_branch`): >> >> (1) clone the repository >> (2) git checkout `bad_branch` >> >> Basically nothing happens. Nothing is printed and I stay on the master >> branch. I also checked $? and there is no error code that is set. If I >> choose any of other branches, it correctly creates a local branch, sets it >> to track the remote and then switches to the local branch. > > Does that branch have a funny name? (i.e. is it ASCII only? Or is it > also utf8 characters? > Does it have some special characters in it like points, colons, > question marks etc) > > Does it happen only with a single sha1 or can you apply commits on top > of that branch > and the error condition persists? > >> >> It seems like there could be some sort of weird bug in the checkout or >> possibly somehow some corruption in the actual object tree. From my vantage >> point, however, the data appears totally fine. For example, in >> `.git/packed-refs` everything appears normal and if I explicitly checkout >> the commit IDs directly (i.e. just copy the commit corresponding to >> refs/remotes/origin/bad_branch and checkout $commit) it checks out fine. If >> I do this with the bad_branch I get a detached HEAD as expected and git log >> lists the commits that it should. >> >> This seems a bit odd to me. There's certainly some sort of error somewhere, >> but it's passing silently. I'm not really sure how to debug this and it's >> too bad I can't actually link the actual repository. I presume if I have the >> time I could try compiling git from source and seeing if it still shows up. >> I tested it on the following two versions of git get the same error: >> >> * 1.9.1 (installed as a package from Linux Mint 17.2 Rafaela) >> * 2.1.4 (installed as a package from Debian Jessie 8.2) > > The refs handling code is in flux at the moment. (starting mid of last > year actually) > I cc'd people who did work recently on the file refs.c > > So I think trying with a new version of Git would be a valuable datapoint! > >> >> Also I should note that the original repository is hosted on Github. >> >> Thanks for any help. Hopefully the fact that I can't provide enough >> information for others to reproduce the issue isn't too large a bother... >> >> Cheers, >> Thomas Nyberg >> -- >> To unsubscribe from this list: send the line "unsubscribe git" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html ``` ## David Turner, 2015-12-14 19:20 Subject: Re: Corruption of branch? Message-ID: <1450120801.1678.13.camel@twopensource.com> URL: https://gitlist.dev/e/1450120801.1678.13.camel%40twopensource.com In-Reply-To: <566F05B2.8080403@gmail.com> ``` On Mon, 2015-12-14 at 13:08 -0500, Thomas Nyberg wrote: > Hi Stefan thanks for much for the response! So I compiled release > version 2.6.4 as well as the current master branch on the git git > repository (2.7.0.rc0.20.g4b9ab0e) and the problem persists on both. > > To answer your questions, there are no weird characters. The name of the > bad_branch is "frus". There is another branch called > "frus_body_cleaning" that is totally fine. What's in .git/config under [branch "frus"] (if anything)? What does "grep refs/heads/frus .git/packed-refs" say? What about find .git -name frus ? Sorry for the possibly-stupid questions, but I'm really baffled by this one. ``` ## Thomas Nyberg, 2015-12-14 19:59 Subject: Re: Corruption of branch? Message-ID: <566F1F96.4060806@gmail.com> URL: https://gitlist.dev/e/566F1F96.4060806%40gmail.com In-Reply-To: <1450120801.1678.13.camel@twopensource.com> ``` In the .git/config there is no [branch "frus"] section. At first this is expected (i.e. cleaning cloning), but nothing changes when I execute `git checkout frus`. When I execute `git checkout frus_body_cleaning` that gets added to .git/config as expected. .git/refs/heads contains two files "master" and "frus_body_cleaning" pointing to their respective commits, but there is nothing else there. here's the other command $ grep frus packed-refs 3a1dbe48299f6eda1cc4b69cab35284c0f0355eb refs/remotes/origin/frus 1750cba5a94b3fe6041aaf49de430a558a3b9bc8 refs/remotes/origin/frus_body_cleaning So here frus actually is showing up. The find command isn't working either. I changed it to add the * but only shows the frus_body_cleaning branch: $ find .git -name 'frus*' .git/logs/refs/heads/frus_body_cleaning .git/refs/heads/frus_body_cleaning So yeah this is pretty weird. I'm guessing you're looking for name collisions of some kind? I had the idea that the problem might that too and used git show-index to look for all objects, but none of them have frus in them (I thought that maybe if the sha of one of them started with "frus" that would explain it but no dice). Since the command `git checkout -b frus origin/frus` works, it seems to me like somehow git is getting confused going from the `git checkout frus` command to that expanded one. It is pretty baffling. On 12/14/2015 02:20 PM, David Turner wrote: > On Mon, 2015-12-14 at 13:08 -0500, Thomas Nyberg wrote: >> Hi Stefan thanks for much for the response! So I compiled release >> version 2.6.4 as well as the current master branch on the git git >> repository (2.7.0.rc0.20.g4b9ab0e) and the problem persists on both. >> >> To answer your questions, there are no weird characters. The name of the >> bad_branch is "frus". There is another branch called >> "frus_body_cleaning" that is totally fine. > > What's in .git/config under [branch "frus"] (if anything)? > > What does "grep refs/heads/frus .git/packed-refs" say? What about > find .git -name frus ? > > Sorry for the possibly-stupid questions, but I'm really baffled by this > one. > ``` ## Dennis Kaarsemaker, 2015-12-14 20:18 Subject: Re: Corruption of branch? Message-ID: <1450124302.16044.1.camel@kaarsemaker.net> URL: https://gitlist.dev/e/1450124302.16044.1.camel%40kaarsemaker.net In-Reply-To: <566F1F96.4060806@gmail.com> ``` On ma, 2015-12-14 at 14:59 -0500, Thomas Nyberg wrote: > I'm guessing you're looking for namecollisions of some kind? I was thinking the same. Can you share the (sanitised) output of git for-each-ref? -- Dennis Kaarsemaker www.kaarsemaker.net ``` ## Thomas Nyberg, 2015-12-14 20:33 Subject: Re: Corruption of branch? Message-ID: <566F277F.4070101@gmail.com> URL: https://gitlist.dev/e/566F277F.4070101%40gmail.com In-Reply-To: <1450124302.16044.1.camel@kaarsemaker.net> ``` What exactly are you looking for? Here's the results of the following command: $ git for-each-ref | grep frus 1750cba5a94b3fe6041aaf49de430a558a3b9bc8 commit refs/heads/frus_body_cleaning 3a1dbe48299f6eda1cc4b69cab35284c0f0355eb commit refs/remotes/origin/frus 1750cba5a94b3fe6041aaf49de430a558a3b9bc8 commit refs/remotes/origin/frus_body_cleaning Sorry if this isn't what you're looking for. I'm actually not very familiar with these different internal git commands... Regardless this looks to me exactly like what I'd expect given the current situation...it's as if I never checked out the "frus" branch at all (which I suppose is true since this is a fresh copy and "git checkout frus" didn't do anything). Btw after checking out explicitly with `git checkout -b frus origin/frus`, things look as I'd expect. $ git for-each-ref | grep frus 3a1dbe48299f6eda1cc4b69cab35284c0f0355eb commit refs/heads/frus 1750cba5a94b3fe6041aaf49de430a558a3b9bc8 commit refs/heads/frus_body_cleaning 3a1dbe48299f6eda1cc4b69cab35284c0f0355eb commit refs/remotes/origin/frus 1750cba5a94b3fe6041aaf49de430a558a3b9bc8 commit refs/remotes/origin/frus_body_cleaning Btw just to test things a little more I deleted both the frus and frus_body_cleaning branches and tried to recheck them out, but the problem still persists. Cheers, Thomas On 12/14/2015 03:18 PM, Dennis Kaarsemaker wrote: > On ma, 2015-12-14 at 14:59 -0500, Thomas Nyberg wrote: >> I'm guessing you're looking for namecollisions of some kind? > > I was thinking the same. Can you share the (sanitised) output of > > git for-each-ref? > ``` ## Dennis Kaarsemaker, 2015-12-14 20:40 Subject: Re: Corruption of branch? Message-ID: <1450125640.16044.4.camel@kaarsemaker.net> URL: https://gitlist.dev/e/1450125640.16044.4.camel%40kaarsemaker.net In-Reply-To: <566F277F.4070101@gmail.com> ``` On ma, 2015-12-14 at 15:33 -0500, Thomas Nyberg wrote: > What exactly are you looking for? Here's the results of the following > command: > > $ git for-each-ref | grep frus > 1750cba5a94b3fe6041aaf49de430a558a3b9bc8 commit > refs/heads/frus_body_cleaning > 3a1dbe48299f6eda1cc4b69cab35284c0f0355eb commit refs/remotes/o > rigin/frus > 1750cba5a94b3fe6041aaf49de430a558a3b9bc8 commit > refs/remotes/origin/frus_body_cleaning > > Sorry if this isn't what you're looking for. I'm actually not very > familiar with these different internal git commands... This is what I was looking for. Unfortunately it doesn't show any of the smoking guns I had hoped for. That leaves only one option: you also have a file or directory named 'frus' in the root of your repository. In this case 'git checkout frus' does the same as 'git checkout -- frus' instead of DWIM'ing 'git checkout frus' to 'git checkout -b frus origin/frus' -- Dennis Kaarsemaker www.kaarsemaker.net ``` ## Junio C Hamano, 2015-12-14 20:42 Subject: Re: Corruption of branch? Message-ID: URL: https://gitlist.dev/e/xmqqr3ioiwyq.fsf%40gitster.mtv.corp.google.com In-Reply-To: <1450125640.16044.4.camel@kaarsemaker.net> ``` Dennis Kaarsemaker writes: > That leaves only one option: you also have a file or directory named > 'frus' in the root of your repository. In this case 'git checkout frus' > does the same as 'git checkout -- frus' instead of DWIM'ing 'git > checkout frus' to 'git checkout -b frus origin/frus' ;-) That would be my guess. ``` ## Thomas Nyberg, 2015-12-14 20:44 Subject: Re: Corruption of branch? Message-ID: <566F2A3B.3050501@gmail.com> URL: https://gitlist.dev/e/566F2A3B.3050501%40gmail.com In-Reply-To: <1450125640.16044.4.camel@kaarsemaker.net> ``` wow right on the button. yeah i have the "frus" folder in the root of my repository. i never knew that git checkout also searches the root of the repository like that. it appears i'm a fool who doesn't read documentation... i learned something knew and can move this from the "bizarre index corruption" category to the "user error" category. thanks so much everyone! On 12/14/2015 03:40 PM, Dennis Kaarsemaker wrote: > On ma, 2015-12-14 at 15:33 -0500, Thomas Nyberg wrote: >> What exactly are you looking for? Here's the results of the following >> command: >> >> $ git for-each-ref | grep frus >> 1750cba5a94b3fe6041aaf49de430a558a3b9bc8 commit >> refs/heads/frus_body_cleaning >> 3a1dbe48299f6eda1cc4b69cab35284c0f0355eb commit refs/remotes/o >> rigin/frus >> 1750cba5a94b3fe6041aaf49de430a558a3b9bc8 commit >> refs/remotes/origin/frus_body_cleaning >> >> Sorry if this isn't what you're looking for. I'm actually not very >> familiar with these different internal git commands... > > This is what I was looking for. Unfortunately it doesn't show any of > the smoking guns I had hoped for. > > That leaves only one option: you also have a file or directory named > 'frus' in the root of your repository. In this case 'git checkout frus' > does the same as 'git checkout -- frus' instead of DWIM'ing 'git > checkout frus' to 'git checkout -b frus origin/frus' > ```