summaryrefslogtreecommitdiff
path: root/sha1_file.c
diff options
context:
space:
mode:
authorJeff King <peff@peff.net>2016-11-08 04:50:17 (GMT)
committerJeff King <peff@peff.net>2016-11-08 20:28:22 (GMT)
commit37a95862c625e1d2ed2609e01b03950253ad4ff9 (patch)
tree4a1c76431a9a96dabe5e655fd36a13a007ce7c1b /sha1_file.c
parentea0fc3b4176a424a2b20eb76a6a503dc4d59cebb (diff)
downloadgit-37a95862c625e1d2ed2609e01b03950253ad4ff9.zip
git-37a95862c625e1d2ed2609e01b03950253ad4ff9.tar.gz
git-37a95862c625e1d2ed2609e01b03950253ad4ff9.tar.bz2
alternates: re-allow relative paths from environment
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>
Diffstat (limited to 'sha1_file.c')
-rw-r--r--sha1_file.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/sha1_file.c b/sha1_file.c
index 0646519..fbafdbe 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -296,7 +296,7 @@ static int link_alt_odb_entry(const char *entry, const char *relative_base,
}
strbuf_addstr(&pathbuf, entry);
- if (strbuf_normalize_path(&pathbuf) < 0) {
+ if (strbuf_normalize_path(&pathbuf) < 0 && relative_base) {
error("unable to normalize alternate object path: %s",
pathbuf.buf);
strbuf_release(&pathbuf);