git-commit-vandalism/t/t5611-clone-config.sh

116 lines
3.1 KiB
Bash
Raw Normal View History

#!/bin/sh
test_description='tests for git clone -c key=value'
. ./test-lib.sh
test_expect_success 'clone -c sets config in cloned repo' '
rm -rf child &&
git clone -c core.foo=bar . child &&
echo bar >expect &&
git --git-dir=child/.git config core.foo >actual &&
test_cmp expect actual
'
test_expect_success 'clone -c can set multi-keys' '
rm -rf child &&
git clone -c core.foo=bar -c core.foo=baz . child &&
{ echo bar; echo baz; } >expect &&
git --git-dir=child/.git config --get-all core.foo >actual &&
test_cmp expect actual
'
test_expect_success 'clone -c can set multi-keys, including some empty' '
rm -rf child &&
git clone -c credential.helper= -c credential.helper=hi . child &&
printf "%s\n" "" hi >expect &&
git --git-dir=child/.git config --get-all credential.helper >actual &&
test_cmp expect actual
'
test_expect_success 'clone -c without a value is boolean true' '
rm -rf child &&
git clone -c core.foo . child &&
echo true >expect &&
git --git-dir=child/.git config --bool core.foo >actual &&
test_cmp expect actual
'
test_expect_success 'clone -c config is available during clone' '
echo content >file &&
git add file &&
git commit -m one &&
rm -rf child &&
git clone -c core.autocrlf . child &&
printf "content\\r\\n" >expect &&
test_cmp expect child/file
'
clone: respect additional configured fetch refspecs during initial fetch The initial fetch during a clone doesn't transfer refs matching additional fetch refspecs given on the command line as configuration variables, e.g. '-c remote.origin.fetch=<refspec>'. This contradicts the documentation stating that configuration variables specified via 'git clone -c <key>=<value> ...' "take effect immediately after the repository is initialized, but before the remote history is fetched" and the given example specifically mentions "adding additional fetch refspecs to the origin remote". Furthermore, one-shot configuration variables specified via 'git -c <key>=<value> clone ...', though not written to the newly created repository's config file, live during the lifetime of the 'clone' command, including the initial fetch. All this implies that any fetch refspecs specified this way should already be taken into account during the initial fetch. The reason for this is that the initial fetch is not a fully fledged 'git fetch' but a bunch of direct calls into the fetch/transport machinery with clone's own refs-to-refspec matching logic, which bypasses parts of 'git fetch' processing configured fetch refspecs. This logic only considers a single default refspec, potentially influenced by options like '--single-branch' and '--mirror'. The configured refspecs are, however, already read and parsed properly when clone calls remote.c:remote_get(), but it never looks at the parsed refspecs in the resulting 'struct remote'. Modify clone to take the remote's configured fetch refspecs into account to retrieve all matching refs during the initial fetch. Note that we have to explicitly add the default fetch refspec to the remote's refspecs, because at that point the remote only includes the fetch refspecs specified on the command line. Add tests to check that refspecs given both via 'git clone -c ...' and 'git -c ... clone' retrieve all refs matching either the default or the additional refspecs, and that it works even when the user specifies an alternative remote name via '--origin=<name>'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-14 11:46:19 +01:00
test_expect_success 'clone -c remote.origin.fetch=<refspec> works' '
rm -rf child &&
git update-ref refs/grab/it refs/heads/master &&
git update-ref refs/leave/out refs/heads/master &&
git clone -c "remote.origin.fetch=+refs/grab/*:refs/grab/*" . child &&
git -C child for-each-ref --format="%(refname)" >actual &&
cat >expect <<-\EOF &&
refs/grab/it
refs/heads/master
refs/remotes/origin/HEAD
refs/remotes/origin/master
EOF
test_cmp expect actual
'
test_expect_success 'git -c remote.origin.fetch=<refspec> clone works' '
rm -rf child &&
git -c "remote.origin.fetch=+refs/grab/*:refs/grab/*" clone . child &&
git -C child for-each-ref --format="%(refname)" >actual &&
cat >expect <<-\EOF &&
refs/grab/it
refs/heads/master
refs/remotes/origin/HEAD
refs/remotes/origin/master
EOF
test_cmp expect actual
'
test_expect_success 'clone -c remote.<remote>.fetch=<refspec> --origin=<name>' '
rm -rf child &&
git clone --origin=upstream \
-c "remote.upstream.fetch=+refs/grab/*:refs/grab/*" \
-c "remote.origin.fetch=+refs/leave/*:refs/leave/*" \
. child &&
git -C child for-each-ref --format="%(refname)" >actual &&
cat >expect <<-\EOF &&
refs/grab/it
refs/heads/master
refs/remotes/upstream/HEAD
refs/remotes/upstream/master
EOF
test_cmp expect actual
'
mingw: introduce the 'core.hideDotFiles' setting On Unix (and Linux), files and directories whose names start with a dot are usually not shown by default. This convention is used by Git: the .git/ directory should be left alone by regular users, and only accessed through Git itself. On Windows, no such convention exists. Instead, there is an explicit flag to mark files or directories as hidden. In the early days, Git for Windows did not mark the .git/ directory (or for that matter, any file or directory whose name starts with a dot) hidden. This lead to quite a bit of confusion, and even loss of data. Consequently, Git for Windows introduced the core.hideDotFiles setting, with three possible values: true, false, and dotGitOnly, defaulting to marking only the .git/ directory as hidden. The rationale: users do not need to access .git/ directly, and indeed (as was demonstrated) should not really see that directory, either. However, not all dot files should be hidden by default, as e.g. Eclipse does not show them (and the user would therefore be unable to see, say, a .gitattributes file). In over five years since the last attempt to bring this patch into core Git, a slightly buggy version of this patch has served Git for Windows' users well: no single report indicated problems with the hidden .git/ directory, and the stream of problems caused by the previously non-hidden .git/ directory simply stopped. The bugs have been fixed during the process of getting this patch upstream. Note that there is a funny quirk we have to pay attention to when creating hidden files: we use Win32's _wopen() function which transmogrifies its arguments and hands off to Win32's CreateFile() function. That latter function errors out with ERROR_ACCESS_DENIED (the equivalent of EACCES) when the equivalent of the O_CREAT flag was passed and the file attributes (including the hidden flag) do not match an existing file's. And _wopen() accepts no parameter that would be transmogrified into said hidden flag. Therefore, we simply try again without O_CREAT. A slightly different method is required for our fopen()/freopen() function as we cannot even *remove* the implicit O_CREAT flag. Therefore, we briefly mark existing files as unhidden when opening them via fopen()/freopen(). The ERROR_ACCESS_DENIED error can also be triggered by opening a file that is marked as a system file (which is unlikely to be tracked in Git), and by trying to create a file that has *just* been deleted and is awaiting the last open handles to be released (which would be handled better by the "Try again?" logic, a story for a different patch series, though). In both cases, it does not matter much if we try again without the O_CREAT flag, read: it does not hurt, either. For details how ERROR_ACCESS_DENIED can be triggered, see https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858 Original-patch-by: Erik Faye-Lund <kusmabite@gmail.com> Initial-Test-By: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-11 10:43:37 +02:00
# Tests for the hidden file attribute on windows
is_hidden () {
# Use the output of `attrib`, ignore the absolute path
case "$(attrib "$1")" in *H*?:*) return 0;; esac
return 1
}
test_expect_success MINGW 'clone -c core.hideDotFiles' '
test_commit attributes .gitattributes "" &&
rm -rf child &&
git clone -c core.hideDotFiles=false . child &&
! is_hidden child/.gitattributes &&
rm -rf child &&
git clone -c core.hideDotFiles=dotGitOnly . child &&
! is_hidden child/.gitattributes &&
rm -rf child &&
git clone -c core.hideDotFiles=true . child &&
is_hidden child/.gitattributes
'
test_done