Git fetch a branch once with a normal name, and on

问题:

I'm fetching for remote branches and stuck in some sort of a loop.

I fetch once and get:

$ git fetch
* [new branch]      minorRelease/something-> origin/minorRelease/something

And then I fetch again and get:

$ git fetch
* [new branch]      minorRelease/Something-> origin/minorRelease/Something

Same branch but with a capital S.

I tried to delete the file from the following folder .git/refs/remotes/origin/minorRelease, but when fetching again, I get both and return to the loop above:

$ git fetch
* [new branch]      minorRelease/Something-> origin/minorRelease/Something
* [new branch]      minorRelease/something-> origin/minorRelease/something

回答1:

@torek is right that it's caused by the difference of Linux and Windows. Linux is case-sensitive, while Windows is not. You can use ls-remote to show the branches in the server.

git ls-remote --heads origin

And I think in your case, the output should include the two branches with only the case of S different.

ref/heads/minorRelease/Something
ref/heads/minorRelease/something

You can delete the remote branch if you find one of them is actually duplicated. And then do fetch again. It should be fine now.

git push origin :minorRelease/Something
git fetch

回答2:

Note: with Git 2.12 (Q1 2017) this will become easier to spot, as you can list branch with a case insensitive option.

See commit 3bb16a8 (04 Dec 2016) by Nguyễn Thái Ngọc Duy (pclouds).
^{(Merged by Junio C Hamano -- gitster -- in commit 73e494f, 19 Dec 2016)}

tag, branch, for-each-ref: add --ignore-case for sorting and filtering.
This options makes sorting ignore case, which is great when you have branches named bug-12-do-something, Bug-12-do-some-more and BUG-12-do-what and want to group them together.
Sorting externally may not be an option because we lose coloring and column layout from git-branch and git-tag.

The same could be said for filtering, but it's probably less important because you can always go with the ugly pattern [bB][uU][gG]-* if you're desperate.

You can't have case-sensitive filtering and case-insensitive sorting (or the other way around) with this though. For branch and tag, that should be no problem. for-each-ref, as a plumbing, might want finer control.
But we can always add --{filter,sort}-ignore-case when there is a need for it.

git branch --ignore-case --list

---

Note: The "--ignore-case" option of "git for-each-ref" (and its friends) did not work correctly, which has been fixed in Git 2.19 (Q3 2018).

See commit 639ab5e (02 Jul 2018) by Aleksandr Makarov (deviance).
See commit e674eb2, commit ee0f3e2 (02 Jul 2018) by Jeff King (peff).
^{(Merged by Junio C Hamano -- gitster -- in commit 4301330, 24 Jul 2018)}

ref-filter: avoid backend filtering with --ignore-case

When for-each-ref is used with --ignore-case, we expect match_name_as_path() to do a case-insensitive match.
But there's an extra layer of filtering that happens before we even get there. Since commit cfe004a (ref-filter: limit traversal to prefix, 2017-05-22, Git v2.14.0), we feed the prefix to the ref backend so that it can optimize the ref iteration.

There's no mechanism for us to tell the backend we're matching case-insensitively. Nor is there likely to be one anytime soon, since the packed backend relies on binary-searching the sorted list of refs.
Let's just punt on this case. The extra filtering is an optimization that we simply can't do. We'll still give the correct answer via the filtering in match_name_as_path().