Why does git keep recreating a branch with a forced update?

Question

Whenever I do a fetch I get a notice from Git saying it has received a forced update and it says a branch is new. It does this for every fetch. I am wondering why this happens, and how I can keep it from happening (meaning fix it). I tried rm .git/refs/remotes/MWNG, but that had no effect.

$ git fetch MWNG
From github.com:MWNG/multikanal.epi7.mysite
 + 022873b...ecaa5df Feature/2005-registrering-sunnhetsbonus -> MWNG/Feature/2005-registrering-sunnhetsbonus  (forced update)
 * [new branch]      feature/2005-registrering-sunnhetsbonus -> MWNG/feature/2005-registrering-sunnhetsbonus
 * [new branch]      feature/azure-rest-api -> MWNG/feature/azure-rest-api

$ git fetch MWNG
From github.com:MWNG/multikanal.epi7.mysite
 + 022873b...ecaa5df Feature/2005-registrering-sunnhetsbonus -> MWNG/Feature/2005-registrering-sunnhetsbonus  (forced update)
 * [new branch]      feature/2005-registrering-sunnhetsbonus -> MWNG/feature/2005-registrering-sunnhetsbonus
 * [new branch]      feature/azure-rest-api -> MWNG/feature/azure-rest-api

As you can see from the above output there are probably two distict, but related problems. One branch has a forced push update and the other not, while both are supposedly new branches every time.

Answer 1

As acsrujan noted in a comment, the issue has to do with case-folding.

The problem can be boiled down to two parts:

1. Git's branch names are case-sensitive.
2. Git's branch names are sometimes stored via file-names, which on some systems, are (sometimes) not case-sensitive.

This causes Git to confuse itself on such systems, precisely at the point at which they are stored via file-names: they become case-insensitive (though, at least, typically case-preserving) at that point, even though they are case-sensitive elsewhere. Now Git doesn't know if it's one branch, or two different branches.

Git may eventually need a general mechanism to deal with this and other issues on MacOS HFS+ and Windows file systems that are set by default to case-preserving-but-insensitive modes (other OSes, including Linux, can do this as well, but don't by default). Until then, your simplest—or maybe I should say least-confusing—method for dealing with this issue is to use or borrow a case-sensitive system (such as a Linux machine), deal with the colliding branches there in all the usual ways, and update them from there to the server.

If that's not available, there is a relatively simple way to fix this particular problem on a case-insensitive (Mac or Windows) client. Note that I have not tested this. It can also be simplified much more if you just need to discard one of the colliding branch-names (see the last paragraph).

1. Run git fetch <remotename>, e.g., git fetch MWNG. This will bring over all the branches and drop their info into .git/FETCH_HEAD, which (since it's file data) will record all the references and their IDs.

2. Pick one of the names to change. Let's say, in this case, you would like to replace Feature/2005-registrering-sunnhetsbonus with feature/joe-used-a-bad-name (lowercase f, and we're blaming Joe, whoever he is). Find the hash ID from FETCH_HEAD, being careful to get the right upper/lower-case mix. If you have a tool like awk you can do this:

   awk '$4 == "'\''Feature/2005-registrering-sunnhetsbonus'\''" { print $1 }' < \
       .git/FETCH_HEAD
   

   but it may be easiest just to view the file (using less or more or your favorite editor).

3. Use git push to create a new, better-named branch pointing to that same ID (which in this case will begin with 022873b):

   git push MWNG 022873b...:refs/heads/feature/joe-used-a-bad-name
   

   (note: you may be able to just use the abbreviated SHA-1 ID, if it's unique. If not, paste in the exact ID, which will definitely work.)

4. Use git push to delete the bad name:

   git push MWNG :Feature/2005-registrering-sunnhetsbonus
   

   (or git push --delete MWNG Feature/2005-registrering-sunnhetsbonus, which is a longer but more memorable way to do the same thing). You can combine this with step 3 as long as you avoid the --delete flag: one git push with both the ID-and-new-name, and empty-string-and-old-name.

5. Last, run git fetch --prune MWNG to update your own repository with the new names.

If you don't need to preserve one version of the name, it's much easier: just do the deletion push on the "bad" name, plus the final fetch-with-prune-option to un-confuse your own Git.