Re: Branch deletion question / possible bug?
- From
Philip Oakley <philipoakley@iee.org>
- Date
- Apr 28, 2018, 10:30 UTC
- Message-ID
- <249C4D418B2B49B4AD5545B912FDA53D@PhilipOakley>
- In-Reply-To
- <CA+P7+xryOt_-vg7cpvqRapM7nWuhWXjhpUR1xi-5MY_RH5UwAQ@mail.gmail.com>
From: "Jacob Keller" <jacob.keller@gmail.com>
Show 32 quoted lines
> On Fri, Apr 27, 2018 at 5:29 PM, Tang (US), Pik S <Pik.S.Tang@boeing.com> > wrote: >> Hi, >> >> I discovered that I was able to delete the feature branch I was in, due >> to some fat fingering on my part and case insensitivity. I never >> realized this could be done before. A quick google search did not give >> me a whole lot to work with... >> >> Steps to reproduce: >> 1. Create a feature branch, "editCss" >> 2. git checkout master >> 3. git checkout editCSS >> 4. git checkout editCss >> 5. git branch -d editCSS >> > > Are you running on a case-insensitive file system? What version of > git? I thought I recalled seeing commits to help avoid creating > branches of the same name with separate case when we know we're on a > file system which is case-insensitive.. > >> Normally, it should have been impossible for a user to delete the branch >> they're on. And the deletion left me in a weird state that took a while >> to dig out of. >> >> I know this was a user error, but I was also wondering if this was a bug. > > If we have not yet done this, I think we should. Long term this would > be fixed by using a separate format to store refs than the filesystem, > which has a few projects being worked on but none have been put into a > release.
Yes, this is an on-going problem on Windows and other case insentive systems. At the moment the branch name becomes embedded as a file name, so when Git requests details of a branch from the filesystem, it can get a case insensitive equivalent. Meanwhile, internally Git is checking for equality in a case sensitive [Linux] way with obvious consequences such as this - The most obvious being when there is no "*" current branch marker in the branch status list.
It's a bit tricky to fix (internally the name and the path are passed down different call chains), and depends on how one expects the case insensitivity to work - the kicker is when someone does an edit of the name via the file system and expects Git to cope (i.e. devs knowing, or think they know, too much detail ;-).
The refs can also get packed, so the "bad spelling" gets baked in. Ultimately it probably means that GfW and other systems will need a case sensitivity check when opening paths...
Philip
Show 11 quoted lines
> > Thanks, > Jake > >> >> >> Thanks, >> >> Pik Tang >> >