From: Philip Oakley Date: Sat, 28 Apr 2018 10:30:21 GMT Subject: Re: Branch deletion question / possible bug? Message-ID: <249C4D418B2B49B4AD5545B912FDA53D@PhilipOakley> In-Reply-To: From: "Jacob Keller" > On Fri, Apr 27, 2018 at 5:29 PM, Tang (US), Pik S > 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 > > Thanks, > Jake > >> >> >> Thanks, >> >> Pik Tang >> >