2

I have a branch called ChartFeature but I accidentally typed git checkout CHartFeature and ended up with this in powershell/poshgit:

C:\git\Charting [CHartFeature]> git status
On branch CHartFeature
nothing to commit, working tree clean

What happened here? If I look in SourceTree it does not show the branch, but I can (and got myself into trouble) when I committed files to this branch which I never created. (I never typed git checkout -b CHartFeature but I did need to merge it into ChartFeature.)

If I list the local branches this erroneous branch does not exist:

C:\git\Charting [CHartFeature]> git branch
  ChartFeature
  develop
  master

What is git doing when I type git checkout CHartFeature without having created that branch? What happened to the commits I made there?

What's more, is it safe to type git branch -d CHartFeature? What would happen if I did?

Matt W
  • 11,753
  • 25
  • 118
  • 215
  • are you using windows ? – LeGEC Mar 03 '17 at 13:48
  • This looks like some else created this branch sometime ago and pushed it accidentially. – ckruczek Mar 03 '17 at 13:51
  • If you're on Windows, where file names are (normally) not case sensitive, you can checkout any case combination of the branch it seems but you're still on the correctly named branch. I just checked out `MAster`, committed a change and checked the log, it looks OK, then I checked out `master`, checked the log and my commit is present. I assume that `git checkout X` just checks if there is a file that can be opened under the refs folder with that name, and on Windows there is, even if the actual filename is `x`. – Lasse V. Karlsen Mar 03 '17 at 13:51
  • @LeGEC yes, Windows 7 – Matt W Mar 03 '17 at 13:52
  • @ckruczek Nope, definitely not. – Matt W Mar 03 '17 at 13:52
  • Note that if I look in the `.git\refs\heads` folder I now have a file named `MAster` which tracks the head of the branch, if I push I assume that the remote repository might not be so "forgiving". In other words, it seems case insensitivity is the reason here but it is not safe to do. – Lasse V. Karlsen Mar 03 '17 at 13:53
  • On Windows those commands are case-insensitive, so you are basically using the intended branch just with a different name. However, you'll probably face problems with `push` because casing matters there, so you will want to fix the case by renaming the file as @phts said in his answer. – Samir Aguiar Mar 03 '17 at 13:53
  • @lasse-v-karlsen The branch list and commits appear to show that I was committing to a different branch. What you've said makes sense, but it is disturbing seeing that I needed to resolve the merge conflict on the intended branch, because I had something like 15 commits to merge across. If it was committing to the intended branch, typo-aside, surely the conflicts would not exist. – Matt W Mar 03 '17 at 13:54
  • @lasse-v-karlsen To your last comment, yes... When I (not yet realising the mistake) tried to push, git complained that I should type git push --set-upstream origin CHartFeature – Matt W Mar 03 '17 at 13:55
  • @lasse-v-karlsen Post your info as an answer and I'll tick it. You're right. – Matt W Mar 03 '17 at 13:58
  • Git is somewhat confused about whether to be case-sensitive or case-insensitive with branch names. See [my answer here](http://stackoverflow.com/a/38494084/1256452) and [VonC's more recent note about Git 2.12](http://stackoverflow.com/a/41307509/1256452). – torek Mar 03 '17 at 20:22

2 Answers2

0

Seems this issue due to case sensitiveness in Windows.

Try to rename ./.git/refs/heads/CHartFeature to ChartFeature manually. Or any CHartFeature presented in .git folder.

phts
  • 3,889
  • 1
  • 19
  • 31
  • The recommended way to rename a branch is using `git branch -m`, not by manually fixing things inside the `.git` folder. – Lasse V. Karlsen Mar 03 '17 at 13:54
  • 1
    @LasseV.Karlsen in theory `git branch -m` shouldn't work, since a branch with a different name was never created. The OP used `git checkout` without the `-b` option. – Samir Aguiar Mar 03 '17 at 13:58
  • Manual renaming is a little tricky as you should also rename the *reflog* file (`.git/logs/refs/heads/CHartFeature`). @kopranb: the `-b` is automatically assumed if there is one (and only one) matching `origin/*` remote-tracking branch. In this case, there was. – torek Mar 03 '17 at 20:14
  • @torek indeed, but it didn't really create a branch since `git branch` doesn't list it. I'm not sure how the OP got merge conflicts though, since his commits should have changed the tip of the branch with the correct name. – Samir Aguiar Mar 03 '17 at 21:04
  • 1
    @kopranb: I don't have his system, but I think the problem here is that it *did* create a branch, in the sort of split-brain manner that happens here: parts of Git believe the two branch names are different, and treat them as different, and parts believe they are the same and treat them that way, and the end result is bad behavior. See http://stackoverflow.com/a/38494084/1256452 and http://stackoverflow.com/a/41307509/1256452 as well. I think this is going to get fixed soonish in a new Git. – torek Mar 03 '17 at 22:06
0

Check what branches exist on your repo :

git branch
git branch -r  # view remote branches

If CHartFeature exists, but ChartFeature doesn't, try renaming your current branch :

git branch -m ChartFeature
LeGEC
  • 46,477
  • 5
  • 57
  • 104