The result of "git branch" does not always highlight the current branch

[hlubovac]

Problem

When a branch is switched to by being named with non-original character-casing, then it's not clear which branch is current.

• [ x] I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options

git version 2.16.1.windows.2
cpu: x86_64
built from commit: e78e3c8
sizeof-long: 4

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

Microsoft Windows [Version 10.0.16299.309]
(version 1709)

• What options did you set as part of the installation? Or did you choose the
  defaults?

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Editor Option: VIM
Path Option: Cmd
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

none comes to mind

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

Same problem manifested via CMD and Bash for Windows

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

C:\repo>git branch
* bar
  foo

C:\repo>git checkout Bar
Switched to branch 'Bar'

C:\repo>git branch
  bar
  foo

• What did you expect to occur after running these commands?

I expected the current branch ("bar") to be emphasized ("* bar).

• What actually happened instead?

The result of "git branch" command did not indicate which of the branches within the output is current.

• If the problem was occurring with a specific repository, can you provide the
  URL to that repository to help us with testing?

n/a

[PhilipOakley]

This is a known issue/limitation (there are other related issue, and notes in the FAQs).

At the moment it is something that needs someone to delve into the code and refactor it (and get it accepted upstream) so that the issue can at least be detected, and then the "right" (user configs?) workarounds implemented.

The uspstream code assumes that all names are case sensitive, and so has no concept that they (the name the user asked for, and the name the file system returned) could become different, so they are not carried around as a structureded item (lots of refactoring needed for that). And even then, getting Windows to quickly tell you the real name it found makes it challenging. Needs a willing dev.

At the moment it's in the "won't be fixed anythime soon without extra help" pile. All help welcome.

[dscho]

While I agree that this is a git-upstream issue, maybe we can entice @hlubovac to help out by delving into the code and fix this for everybody?

The only tricky issue here is that the branch names are not necessarily bound to the limitations of the filesystem: support for refs backends was added recently. As long as we keep in mind that a future refs backend may allow case-sensitive refs even on a case-insensitive filesystem.

@hlubovac are you up for an adventure in C? If so, please start by either

• cloning https://github.com/git-for-windows/git, checking out the vs/master branch and opening git.sln in Visual Studio, or

• (if you are more comfortable with GCC): clone git clone --depth 1 https://github.com/git-for-windows/git-sdk-64 and then run the git-bash.exe from the top-level directory of that worktree

Then, build Git yourself, just to see that all the knobs are working. In Visual Studio, just do a full build. In the SDK, call sdk build git.

Let me know how this is going, I will assemble some pointers for guidance with the next steps.

[dscho]

So here are a few more hints:

• the source code for git checkout is located in builtin/checkout.c.
• the git checkout command is unfortunately a hybrid of two commands that do quite a bit different things: git checkout [<tree-ish>] [--] <pathspec>... does not switch the branch, instead it picks the specified files' revisions from Git's database and writes them to the worktree, but stays on the current branch. The syntax git checkout <ref>, however, changes the current branch.
• the conditional block to change the current branch is here:

  git/builtin/checkout.c

  Line 1262 in 7e4058d

  return checkout_branch(&opts, &new_branch_info);

  
  The information about the branch name is stored in the variable new_branch_info.
• this calls the checkout_branch() function:

  git/builtin/checkout.c

  Line 1046 in 7e4058d

  static int checkout_branch(struct checkout_opts *opts,

  which in turn calls switch_branches():

  git/builtin/checkout.c

  Line 816 in 7e4058d

  static int switch_branches(const struct checkout_opts *opts,

• eventually, this calls update_refs_for_switch() where HEAD is updated:

  git/builtin/checkout.c

  Lines 681 to 701 in 7e4058d

  	} else if (new_branch_info->path) { /* Switch branches. */
  	if (create_symref("HEAD", new_branch_info->path, msg.buf) < 0)
  	die(_("unable to update HEAD"));
  	if (!opts->quiet) {
  	if (old_branch_info->path && !strcmp(new_branch_info->path, old_branch_info->path)) {
  	if (opts->new_branch_force)
  	fprintf(stderr, _("Reset branch '%s'\n"),
  	new_branch_info->name);
  	else
  	fprintf(stderr, _("Already on '%s'\n"),
  	new_branch_info->name);
  	} else if (opts->new_branch) {
  	if (opts->branch_exists)
  	fprintf(stderr, _("Switched to and reset branch '%s'\n"), new_branch_info->name);
  	else
  	fprintf(stderr, _("Switched to a new branch '%s'\n"), new_branch_info->name);
  	} else {
  	fprintf(stderr, _("Switched to branch '%s'\n"),
  	new_branch_info->name);
  	}
  	}

• there is a (for our purposes) really interesting field name here, called branch_exists:

  git/builtin/checkout.c

  Line 693 in 7e4058d

  if (opts->branch_exists)

  
  However, that field is only in use when Git was asked to create a new branch (via git checkout -b <new-branch-name>):

  git/builtin/checkout.c

  Lines 1247 to 1256 in 7e4058d

  	if (opts.new_branch) {
  	struct strbuf buf = STRBUF_INIT;
  	if (opts.new_branch_force)
  	opts.branch_exists = validate_branchname(opts.new_branch, &buf);
  	else
  	opts.branch_exists =
  	validate_new_branchname(opts.new_branch, &buf, 0);
  	strbuf_release(&buf);
  	}

  
  Note that this is also a place where Git needs to be fixed for case-insensitive ref names.
• the validation of the specified branch name seems to happen in parse_branchname_arg():

  git/builtin/checkout.c

  Lines 995 to 997 in 7e4058d

  	if (!check_refname_format(new_branch_info->path, 0) &&
  	!read_ref(new_branch_info->path, &branch_rev))
  	oidcpy(rev, &branch_rev);

  
  This would be a logical place to add some validation also for the non-new_branch case.
• note how the validate_branchname() takes a strbuf as second parameter?

  git/branch.h

  Lines 31 to 36 in 7e4058d

  	/*
  	* Check if 'name' can be a valid name for a branch; die otherwise.
  	* Return 1 if the named branch already exists; return 0 otherwise.
  	* Fill ref with the full refname for the branch.
  	*/
  	extern int validate_branchname(const char *name, struct strbuf *ref);

  
  This is obviously a place where we could adjust the case. So far, it does not seem as if there is any support for that, though, as the code to test whether a ref exists only takes the ref name as a read-only parameter:

  git/branch.c

  Line 191 in 7e4058d

  return ref_exists(ref->buf);

  
  To fix this, we need to add a new function to "canonicalize" a given ref name.

The real trick, then, will be to canonicalize a given file name to the version stored on disk. We already have code for that, but that's only in the Windows-specific part (and thus, it won't work on macOS, or on Linux with a case-insensitive filesystem):

git/compat/mingw.c

Lines 1045 to 1065 in 7e4058d

	ret = GetLongPathNameW(cwd, wpointer, ARRAY_SIZE(wpointer));
	if (!ret && GetLastError() == ERROR_ACCESS_DENIED &&
	INIT_PROC_ADDR(GetFinalPathNameByHandleW)) {
	HANDLE hnd = CreateFileW(cwd, 0,
	FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, NULL,
	OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS, NULL);
	if (hnd == INVALID_HANDLE_VALUE)
	return NULL;
	ret = GetFinalPathNameByHandleW(hnd, wpointer, ARRAY_SIZE(wpointer), 0);
	CloseHandle(hnd);
	if (!ret || ret >= ARRAY_SIZE(wpointer))
	return NULL;
	if (xwcstoutf(pointer, normalize_ntpath(wpointer), len) < 0)
	return NULL;
	return pointer;
	}
	if (!ret || ret >= ARRAY_SIZE(wpointer))
	return NULL;
	if (xwcstoutf(pointer, wpointer, len) < 0)
	return NULL;
	convert_slashes(pointer);

But maybe we do not have to come up with a full solution right away? Maybe we can just come up with a Windows-only solution for starters, and the good macOS users can then work out a solution that works on macOS, too, and the good Linux folks could then even make sure that they have a solution, too (e.g. when working on a FAT filesystem or on a Windows share mounted via CIFS; it seems that GNU libc has a canonicalize_file_name() that might do the job).

The thing I have in mind here is a function a la has_dos_drive_prefix(), which is defined for Windows in compat/mingw.h, and a fall-back is implemented in git-compat-util.h.

[dscho]

Oh, and I forgot to mention that it might be best to add a regression test first, demonstrating that there is a bug.

Personally, I would probably add this to the t/t2018-checkout-branch.sh script, and it would have to be marked with the CASE_INSENSITIVE_FS prerequisite. Something like

test_expect_failure CASE_INSENSITIVE_FS 'branch name with funny cAsInG' '
    git checkout -b fUnNy-CaSe &&
    : "switch away" from the current branch &&
    git checkout HEAD^0 &&
    : come back, but with different casing &&
    git checkout funny-case &&
    git branch | grep "^\\*" >actual &&
    grep fUnNy-CaSe actual
'

(This was just jotted down in the browser and probably will need a couple of fixes before it does what it is intended to do.)

[dscho]

After discussing this problem with @mhagger (our resident refs magician), it would appear that maybe my idea to canonicalize the refs ("DWIM it", i.e. "Do What I Mean") is probably not the best idea. A better idea would be to disallow resolving refs when they are specified using the wrong case.

And this only relates to the loose refs anyway. Once they are packed, the ref will not be resolved case-insensitively. So that makes it possible for you to think you are on a valid branch, run git gc, and then Git complains about a missing ref and nothing works anymore.

So let's try to go into a slightly different direction: let's start deprecating, and eventually disallowing, refs specified in the wrong case.

In particular, I am looking at the files_read_raw_ref() function, where we lstat() the path without regard for any case-insensitivity issues:

git/refs/files-backend.c

Line 349 in 7e4058d

if (lstat(path, &st) < 0) {

The fix I have in mind would test whether we are on a case-insensitive filesystem (via the global variable ignore_case) and if so, try to canonicalize the path using that new function I was envisioning above, then match the suffix against the specified ref, and complain if they differ.

Then, we would introduce a config variable that makes this a fatal error, first opt-in, and in a later version opt-out.

How does that sound?

[hlubovac]

I'm sorry that I'm going to disappoint you all, but I'm not a C developer. I did, out of curiousity, checked-out the mentioned branch, installed C/C++ SDK for my Visual Studio, compiled the solution, took a look at checkout.c file - but I'm not comfortable editing, etc. I'll take another look: perhaps I'll change my mind after I figure out how to step through and see my use-cases executed by that code (as opposed to installed git.exe), and I'll try to make sense out of what's been mentioned above related to locations of interest within that code base, but I cannot make any promises at the moment.

I am curious, though, to find out why case-insesitivity needs to be supported in the first place? Would it not be simpler to simply reject the checkout command if the name that follows doesn't exactly match an existing branch (provided -b option isn't included)? I'm not sure that I follow what somebody above said about checking-out files (as opposed to branches), as I didn't know that was an option - so, this question would possibly be self-explanatory to you, while that part is confusing me a little. Thanks.

[siprbaum]

Git also supports checking out files, e.g. if you say git checkout foo it will checkout a file foo
from the index (assuming there is one). But what happens if you also have a branch foo?

Git then doesn't know if you meant

• checkout a file

or if you meant

• switch to the foo branch

To differentiate between branch and file, on can use the -- as seperator to tell git,
anything what follows the -- shall be interpreted as a file.

Examples:

• git checkout -- foo will checkout the file foo
• git checkout foo -- will switch to the branch foo

For further information, see the synopsis of the git checkout command e.g. by running git help checkout

[dscho]

I'm sorry that I'm going to disappoint you all, but I'm not a C developer

No need to be sorry, because the only one you are disappointing is yourself: the only way to make sure that your issue gets resolved is to get behind it.

why case-insesitivity needs to be supported in the first place?

Git originally stores all refs (including branches) as plain files. As a consequence, you can access them using the incorrect case. But when you enumerate them (and match them case-sensitively, as Git does), it leads to nasty surprises, as your bug report shows.

However, git gc packs the refs. And once they are packed, there is no way Git will let you access the ref unless you specify it with the exact spelling.

Would it not be simpler to simply reject the checkout command if the name that follows doesn't exactly match an existing branch

That is exactly what I proposed here.

The trick is to find out what the spelling of the file name is, once it was successfully opened with a possibly incorrect spelling. Hence my suggestion to use GetLongPathName() and/or GetFinalPathByHandle(), which would allow you to do precisely that (on Windows).

[PhilipOakley]

In a parrallel universe, https://public-inbox.org/git/CAP8UFD0PPZSjBnxCA7ez91vBuatcHKQ+JUWvTD1iHcXzPBjPBg@mail.gmail.com/#r
the upstream are also looking at creating a "reftable" [1] that would partially eliminate this issue (excepting backward compatibility).

[1] a table of the references in use, such as branch names https://git-scm.com/book/en/v2/Git-Internals-Git-References and https://git-scm.com/docs/gitrevisions <refname>

Let's hope bothe approaches bring benefits.