summaryrefslogtreecommitdiff
path: root/t/t5615-alternate-env.sh
AgeCommit message (Collapse)AuthorFilesLines
2017-12-08t5615: avoid re-using descriptor 4Libravatar Jeff King1-3/+3
File descriptors 3 and 4 are special in our test suite, as they link back to the test script's original stdout and stderr. Normally this isn't something tests need to worry about: they are free to clobber these descriptors for sub-commands without affecting the overall script. But there's one very special thing about descriptor 4: since d88785e424 (test-lib: set BASH_XTRACEFD automatically, 2016-05-11), we ask bash to output "set -x" output to it by number. This goes to _any_ descriptor 4, even if it no longer points to the place it did when we set BASH_XTRACEFD. But in t5615, we run a shell loop with descriptor 4 redirected. As a result, t5615 works with non-bash shells even with "-x". And it works with bash without "-x". But the combination of "bash t5615-alternate-env.sh -x" gets a test failure (because our "set -x" output pollutes one of the files). We can fix this by using any descriptor _except_ the magical 4. So let's switch arbitrarily to using 5/6 in this loop, not 3/4. Another alternative is to use a different descriptor for BASH_XTRACEFD. But picking an unused one turns out to be hard. Most shells limit us to 9 numbered descriptors. Bash can handle more, but: - while the BASH_XTRACEFD is specific to bash, GIT_TRACE=4 has a similar problem, and would affect all shells - constructs like "999>/dev/null" are synticatically invalid to non-bash shells. So we have to actually bury it inside an eval, which creates more complications. Of the numbers 1-9, you might think that "9" would be less used than "4". But it's not; many of our scripts use descriptors 8 and 9 (probably under the assumption that they are high and therefore unused). The least-used descriptor is currently "7". We could switch to that, but we're just trading one magic number for another. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-27Merge branch 'jk/quote-env-path-list-component'Libravatar Junio C Hamano1-0/+1
A test fix. * jk/quote-env-path-list-component: t5615: fix a here-doc syntax error
2017-03-22t5615: fix a here-doc syntax errorLibravatar Junio C Hamano1-0/+1
This came as part of jk/quote-env-path-list-component and was merged to 2.11.1 and later. Noticed-by: Jan Palus <jan.palus@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-21Merge branch 'jk/quote-env-path-list-component'Libravatar Junio C Hamano1-0/+18
A recent update to receive-pack to make it easier to drop garbage objects made it clear that GIT_ALTERNATE_OBJECT_DIRECTORIES cannot have a pathname with a colon in it (no surprise!), and this in turn made it impossible to push into a repository at such a path. This has been fixed by introducing a quoting mechanism used when appending such a path to the colon-separated list. * jk/quote-env-path-list-component: t5615-alternate-env: double-quotes in file names do not work on Windows t5547-push-quarantine: run the path separator test on Windows, too tmp-objdir: quote paths we add to alternates alternates: accept double-quoted paths
2016-12-21t5615-alternate-env: double-quotes in file names do not work on WindowsLibravatar Johannes Sixt1-1/+1
Protect a recently added test case with !MINGW. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-12alternates: accept double-quoted pathsLibravatar Jeff King1-0/+18
We read lists of alternates from objects/info/alternates files (delimited by newline), as well as from the GIT_ALTERNATE_OBJECT_DIRECTORIES environment variable (delimited by colon or semi-colon, depending on the platform). There's no mechanism for quoting the delimiters, so it's impossible to specify an alternate path that contains a colon in the environment, or one that contains a newline in a file. We've lived with that restriction for ages because both alternates and filenames with colons are relatively rare, and it's only a problem when the two meet. But since 722ff7f87 (receive-pack: quarantine objects until pre-receive accepts, 2016-10-03), which builds on the alternates system, every push causes the receiver to set GIT_ALTERNATE_OBJECT_DIRECTORIES internally. It would be convenient to have some way to quote the delimiter so that we can represent arbitrary paths. The simplest thing would be an escape character before a quoted delimiter (e.g., "\:" as a literal colon). But that creates a backwards compatibility problem: any path which uses that escape character is now broken, and we've just shifted the problem. We could choose an unlikely escape character (e.g., something from the non-printable ASCII range), but that's awkward to use. Instead, let's treat names as unquoted unless they begin with a double-quote, in which case they are interpreted via our usual C-stylke quoting rules. This also breaks backwards-compatibility, but in a smaller way: it only matters if your file has a double-quote as the very _first_ character in the path (whereas an escape character is a problem anywhere in the path). It's also consistent with many other parts of git, which accept either a bare pathname or a double-quoted one, and the sender can choose to quote or not as required. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-11-11t0021, t5615: use $PWD instead of $(pwd) in PATH-like shell variablesLibravatar Johannes Sixt1-2/+2
We have to use $PWD instead of $(pwd) because on Windows the latter would add a C: style path to bash's Unix-style $PATH variable, which becomes confused by the colon after the drive letter. ($PWD is a Unix-style path.) In the case of GIT_ALTERNATE_OBJECT_DIRECTORIES, bash on Windows assembles a Unix-style path list with the colon as separators. It converts the value to a Windows-style path list with the semicolon as path separator when it forwards the variable to git.exe. The same confusion happens when bash's original value is contaminated with Windows style paths. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-11-08alternates: re-allow relative paths from environmentLibravatar Jeff King1-0/+71
Commit 670c359da (link_alt_odb_entry: handle normalize_path errors, 2016-10-03) regressed the handling of relative paths in the GIT_ALTERNATE_OBJECT_DIRECTORIES variable. It's not entirely clear this was ever meant to work, but it _has_ worked for several years, so this commit restores the original behavior. When we get a path in GIT_ALTERNATE_OBJECT_DIRECTORIES, we add it the path to the list of alternate object directories as if it were found in objects/info/alternates, but with one difference: we do not provide the link_alt_odb_entry() function with a base for relative paths. That function doesn't turn it into an absolute path, and we end up feeding the relative path to the strbuf_normalize_path() function. Most relative paths break out of the top-level directory (e.g., "../foo.git/objects"), and thus normalizing fails. Prior to 670c359da, we simply ignored the error, and due to the way normalize_path_copy() was implemented it happened to return the original path in this case. We then accessed the alternate objects using this relative path. By storing the relative path in the alt_odb list, the path is relative to wherever we happen to be at the time we do an object lookup. That means we look from $GIT_DIR in a bare repository, and from the top of the worktree in a non-bare repository. If this were being designed from scratch, it would make sense to pick a stable location (probably $GIT_DIR, or even the object directory) and use that as the relative base, turning the result into an absolute path. However, given the history, at this point the minimal fix is to match the pre-670c359da behavior. We can do this simply by ignoring the error when we have no relative base and using the original value (which we now reliably have, thanks to strbuf_normalize_path()). That still leaves us with a relative path that foils our duplicate detection, and may act strangely if we ever chdir() later in the process. We could solve that by storing an absolute path based on getcwd(). That may be a good future direction; for now we'll do just the minimum to fix the regression. The new t5615 script demonstrates the fix in its final three tests. Since we didn't have any tests of the alternates environment variable at all, it also adds some tests of absolute paths. Reported-by: Bryan Turner <bturner@atlassian.com> Signed-off-by: Jeff King <peff@peff.net>