{"thread":{"id":"48373","subject":"Branch deletion question / possible bug?","startedAt":"2018-04-28T00:35:58Z","lastAt":"2018-04-30T19:54:27Z","messageCount":5,"participants":["Tang (US), Pik S","Jacob Keller","Philip Oakley","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"346018","messageId":"d4d8d8208b6a41c380ecf20807763bcf@XCH15-05-02.nw.nos.boeing.com","threadId":"48373","inReplyTo":null,"subject":"Branch deletion question / possible bug?","fromName":"Tang (US), Pik S","fromEmail":"pik.s.tang@boeing.com","sentAt":"2018-04-28T00:29:19Z","receivedAt":"2018-04-28T00:35:58Z","isPatch":false,"sender":{"key":"pik.s.tang@boeing.com","avatar":null},"body":"Hi,\n\nI 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... \n\nSteps to reproduce:\n1. Create a feature branch, \"editCss\"\n2. git checkout master\n3. git checkout editCSS\n4. git checkout editCss\n5. git branch -d editCSS\n\nNormally, 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.\n\nI know this was a user error, but I was also wondering if this was a bug.\n\n\nThanks,\n\nPik Tang\n\n"},{"id":"346026","messageId":"CA+P7+xryOt_-vg7cpvqRapM7nWuhWXjhpUR1xi-5MY_RH5UwAQ@mail.gmail.com","threadId":"48373","inReplyTo":"d4d8d8208b6a41c380ecf20807763bcf@XCH15-05-02.nw.nos.boeing.com","subject":"Re: Branch deletion question / possible bug?","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2018-04-28T07:44:56Z","receivedAt":"2018-04-28T07:45:21Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Fri, Apr 27, 2018 at 5:29 PM, Tang (US), Pik S wrote:\n> Hi,\n>\n> 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...\n>\n> Steps to reproduce:\n> 1. Create a feature branch, \"editCss\"\n> 2. git checkout master\n> 3. git checkout editCSS\n> 4. git checkout editCss\n> 5. git branch -d editCSS\n>\n\nAre you running on a case-insensitive file system? What version of\ngit? I thought I recalled seeing commits to help avoid creating\nbranches of the same name with separate case when we know we're on a\nfile system which is case-insensitive..\n\n> 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.\n>\n> I know this was a user error, but I was also wondering if this was a bug.\n\nIf we have not yet done this, I think we should. Long term this would\nbe fixed by using a separate format to store refs than the filesystem,\nwhich has a few projects being worked on but none have been put into a\nrelease.\n\nThanks,\nJake\n\n>\n>\n> Thanks,\n>\n> Pik Tang\n>\n"},{"id":"346029","messageId":"249C4D418B2B49B4AD5545B912FDA53D@PhilipOakley","threadId":"48373","inReplyTo":"CA+P7+xryOt_-vg7cpvqRapM7nWuhWXjhpUR1xi-5MY_RH5UwAQ@mail.gmail.com","subject":"Re: Branch deletion question / possible bug?","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2018-04-28T10:30:21Z","receivedAt":"2018-04-28T10:30:29Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Jacob Keller\" \n> On Fri, Apr 27, 2018 at 5:29 PM, Tang (US), Pik S \n> wrote:\n>> Hi,\n>>\n>> I discovered that I was able to delete the feature branch I was in, due\n>> to some fat fingering on my part and case insensitivity. I never\n>> realized this could be done before. A quick google search did not give\n>> me a whole lot to work with...\n>>\n>> Steps to reproduce:\n>> 1. Create a feature branch, \"editCss\"\n>> 2. git checkout master\n>> 3. git checkout editCSS\n>> 4. git checkout editCss\n>> 5. git branch -d editCSS\n>>\n>\n> Are you running on a case-insensitive file system? What version of\n> git? I thought I recalled seeing commits to help avoid creating\n> branches of the same name with separate case when we know we're on a\n> file system which is case-insensitive..\n>\n>> Normally, it should have been impossible for a user to delete the branch\n>> they're on. And the deletion left me in a weird state that took a while\n>> to dig out of.\n>>\n>> I know this was a user error, but I was also wondering if this was a bug.\n>\n> If we have not yet done this, I think we should. Long term this would\n> be fixed by using a separate format to store refs than the filesystem,\n> which has a few projects being worked on but none have been put into a\n> release.\n\nYes, this is an on-going problem on Windows and other case insentive\nsystems. At the moment the branch name becomes embedded as a file name, so\nwhen Git requests details of a branch from the filesystem, it can get a case\ninsensitive equivalent. Meanwhile, internally Git is checking for equality\nin a case sensitive [Linux] way with obvious consequences such as this - The\nmost obvious being when there is no \"*\" current branch marker in the branch\nstatus list.\n\nIt's a bit tricky to fix (internally the name and the path are passed down\ndifferent call chains), and depends on how one expects the case\ninsensitivity to work - the kicker is when someone does an edit of the name\nvia the file system and expects Git to cope (i.e. devs knowing, or think\nthey know, too much detail ;-).\n\nThe refs can also get packed, so the \"bad spelling\" gets baked in.\nUltimately it probably means that GfW and other systems will need a case\nsensitivity check when opening paths...\n\nPhilip\n>\n> Thanks,\n> Jake\n>\n>>\n>>\n>> Thanks,\n>>\n>> Pik Tang\n>>\n>\n\n"},{"id":"346035","messageId":"nycvar.QRO.7.76.6.1804281440570.79@tvgsbejvaqbjf.bet","threadId":"48373","inReplyTo":"249C4D418B2B49B4AD5545B912FDA53D@PhilipOakley","subject":"Re: Branch deletion question / possible bug?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2018-04-28T12:43:30Z","receivedAt":"2018-04-28T12:43:45Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 28 Apr 2018, Philip Oakley wrote:\n\n> From: \"Jacob Keller\" \n> > On Fri, Apr 27, 2018 at 5:29 PM, Tang (US), Pik S \n> > wrote:\n> > > Hi,\n> > >\n> > > I discovered that I was able to delete the feature branch I was in, due\n> > > to some fat fingering on my part and case insensitivity. I never\n> > > realized this could be done before. A quick google search did not give\n> > > me a whole lot to work with...\n> > >\n> > > Steps to reproduce:\n> > > 1. Create a feature branch, \"editCss\"\n> > > 2. git checkout master\n> > > 3. git checkout editCSS\n> > > 4. git checkout editCss\n> > > 5. git branch -d editCSS\n> > >\n> >\n> > Are you running on a case-insensitive file system? What version of\n> > git? I thought I recalled seeing commits to help avoid creating\n> > branches of the same name with separate case when we know we're on a\n> > file system which is case-insensitive..\n> >\n> > > Normally, it should have been impossible for a user to delete the branch\n> > > they're on. And the deletion left me in a weird state that took a while\n> > > to dig out of.\n> > >\n> > > I know this was a user error, but I was also wondering if this was a bug.\n> >\n> > If we have not yet done this, I think we should. Long term this would\n> > be fixed by using a separate format to store refs than the filesystem,\n> > which has a few projects being worked on but none have been put into a\n> > release.\n> \n> Yes, this is an on-going problem on Windows and other case insentive\n> systems. At the moment the branch name becomes embedded as a file name, so\n> when Git requests details of a branch from the filesystem, it can get a case\n> insensitive equivalent. Meanwhile, internally Git is checking for equality\n> in a case sensitive [Linux] way with obvious consequences such as this - The\n> most obvious being when there is no \"*\" current branch marker in the branch\n> status list.\n> \n> It's a bit tricky to fix (internally the name and the path are passed down\n> different call chains), and depends on how one expects the case\n> insensitivity to work - the kicker is when someone does an edit of the name\n> via the file system and expects Git to cope (i.e. devs knowing, or think\n> they know, too much detail ;-).\n> \n> The refs can also get packed, so the \"bad spelling\" gets baked in.\n> Ultimately it probably means that GfW and other systems will need a case\n> sensitivity check when opening paths...\n\nFWIW I outlined what I think is the best route to fix this for good:\n\nhttps://github.com/git-for-windows/git/issues/1623#issuecomment-380085257\n\nEssentially, I think we should teach Git the trick to check the spelling\nbefore calling lstat() in refs/files-backend.c.\n\nTo check the spelling, we would need an API to get the on-disk\nrepresentation of a given path. On Windows, I know this call. On Linux,\napparently canonicalize_file_name() might do the job, but that is a GNU\nlibc extension, and won't help us on macOS.\n\nAny ideas?\n\nCiao,\nDscho\n"},{"id":"346189","messageId":"d7786ad6fd0e42c7ae789075076be6eb@XCH15-05-02.nw.nos.boeing.com","threadId":"48373","inReplyTo":"nycvar.QRO.7.76.6.1804281440570.79@tvgsbejvaqbjf.bet","subject":"RE: Branch deletion question / possible bug?","fromName":"Tang (US), Pik S","fromEmail":"pik.s.tang@boeing.com","sentAt":"2018-04-30T19:54:16Z","receivedAt":"2018-04-30T19:54:27Z","isPatch":false,"sender":{"key":"pik.s.tang@boeing.com","avatar":null},"body":"Hello,\n\nThank you for all your replies. I am on a case insensitive system (Windows 10) running git version 2.14.1.windows.1. \n\nWhile I can't comment on what the fix would be, it has been enlightening to learn a bit more about what's under the cover of git. \n\nTIL :)\nPik\n\n-----Original Message-----\nFrom: Johannes Schindelin [mailto:Johannes.Schindelin@gmx.de] \nSent: Saturday, April 28, 2018 5:44 AM\nTo: Philip Oakley \nCc: Jacob Keller ; Tang (US), Pik S ; Git List \nSubject: Re: Branch deletion question / possible bug?\n\nHi,\n\nOn Sat, 28 Apr 2018, Philip Oakley wrote:\n\n> From: \"Jacob Keller\" \n> > On Fri, Apr 27, 2018 at 5:29 PM, Tang (US), Pik S \n> > \n> > wrote:\n> > > Hi,\n> > >\n> > > I discovered that I was able to delete the feature branch I was \n> > > in, due to some fat fingering on my part and case insensitivity. \n> > > I never realized this could be done before. A quick google search \n> > > did not give me a whole lot to work with...\n> > >\n> > > Steps to reproduce:\n> > > 1. Create a feature branch, \"editCss\"\n> > > 2. git checkout master\n> > > 3. git checkout editCSS\n> > > 4. git checkout editCss\n> > > 5. git branch -d editCSS\n> > >\n> >\n> > Are you running on a case-insensitive file system? What version of \n> > git? I thought I recalled seeing commits to help avoid creating \n> > branches of the same name with separate case when we know we're on a \n> > file system which is case-insensitive..\n> >\n> > > Normally, it should have been impossible for a user to delete the \n> > > branch they're on. And the deletion left me in a weird state that \n> > > took a while to dig out of.\n> > >\n> > > I know this was a user error, but I was also wondering if this was a bug.\n> >\n> > If we have not yet done this, I think we should. Long term this \n> > would be fixed by using a separate format to store refs than the \n> > filesystem, which has a few projects being worked on but none have \n> > been put into a release.\n> \n> Yes, this is an on-going problem on Windows and other case insentive \n> systems. At the moment the branch name becomes embedded as a file \n> name, so when Git requests details of a branch from the filesystem, it \n> can get a case insensitive equivalent. Meanwhile, internally Git is \n> checking for equality in a case sensitive [Linux] way with obvious \n> consequences such as this - The most obvious being when there is no \n> \"*\" current branch marker in the branch status list.\n> \n> It's a bit tricky to fix (internally the name and the path are passed \n> down different call chains), and depends on how one expects the case \n> insensitivity to work - the kicker is when someone does an edit of the \n> name via the file system and expects Git to cope (i.e. devs knowing, \n> or think they know, too much detail ;-).\n> \n> The refs can also get packed, so the \"bad spelling\" gets baked in.\n> Ultimately it probably means that GfW and other systems will need a \n> case sensitivity check when opening paths...\n\nFWIW I outlined what I think is the best route to fix this for good:\n\nhttps://github.com/git-for-windows/git/issues/1623#issuecomment-380085257\n\nEssentially, I think we should teach Git the trick to check the spelling before calling lstat() in refs/files-backend.c.\n\nTo check the spelling, we would need an API to get the on-disk representation of a given path. On Windows, I know this call. On Linux, apparently canonicalize_file_name() might do the job, but that is a GNU libc extension, and won't help us on macOS.\n\nAny ideas?\n\nCiao,\nDscho\n\n\n"}]}