]> git.ipfire.org Git - thirdparty/git.git/commit - setup.c
Fix .git/ discovery at the root of UNC shares
authorJohannes Schindelin <johannes.schindelin@gmx.de>
Sat, 24 Aug 2019 22:10:45 +0000 (15:10 -0700)
committerJunio C Hamano <gitster@pobox.com>
Mon, 26 Aug 2019 17:03:41 +0000 (10:03 -0700)
commite2683d51d96f5e95489d29ee6dfafdde790579e4
treed9541af473ce436ba947072aaaea83ae7d572a22
parentd17f2124a7860c2f37eaba574a867dbb4f506c27
Fix .git/ discovery at the root of UNC shares

A very common assumption in Git's source code base is that
offset_1st_component() returns either 0 for relative paths, or 1 for
absolute paths that start with a slash. In other words, the return value
is either 0 or points just after the dir separator.

This assumption is not fulfilled when calling offset_1st_component()
e.g. on UNC paths on Windows, e.g. "//my-server/my-share". In this case,
offset_1st_component() returns the length of the entire string (which is
correct, because stripping the last "component" would not result in a
valid directory), yet the return value still does not point just after a
dir separator.

This assumption is most prominently seen in the
setup_git_directory_gently_1() function, where we want to append a
".git" component and simply assume that there is already a dir
separator. In the UNC example given above, this assumption is incorrect.

As a consequence, Git will fail to handle a worktree at the top of a UNC
share correctly.

Let's fix this by adding a dir separator specifically for that case: we
found that there is no first component in the path and it does not end
in a dir separator? Then add it.

This fixes https://github.com/git-for-windows/git/issues/1320

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
setup.c