Junio C Hamano wrote: > then I've always thought that is simply a misconfiguration (t0002 > seems to use full path for this exact reason). Everything in that test works with REAL=.real except the line test "$REAL" = "$(git rev-parse --git-dir)" because --git-dir returns an absolute path. > Is there a reason why relative path should be used/usable here, other > than "being able to is better than not being able to"??? Similar configurations already work: - A .git file with a relative path works inside its work tree - A .git symlink with a relative path works inside its work tree - A submodule whose .git is a real symlink with a relative path works My patch just fixes an intuitive combination of these cases. > I don't like my process randomly chdir'ing around assuming they can > chdir back safely very much, and would prefer not to add such > codepaths unless absolutely necessary. Here is a new patch series. Patch 1/2 is unchanged. Patch 2/2 has been re-written to avoid chdir. Avery Pennarun wrote: > This problem seems especially true with submodules. If the > submodule's repo is something like supermodule/.git/submodule.git, a > relative path would almost always be a appropriate, no? Exactly. In fact the experiment I was doing involved creating submodule repos inside the main .git and linking to them from the work tree subdirectories. I'm looking into combining the approach with that of git-new-workdir to keep submodules in the same object database. Brad King (2): Test update-index for a gitlink to a .git file Handle relative paths in submodule .git files setup.c | 22 +++++++++++++++++++--- t/t2104-update-index-gitfile.sh | 38 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 57 insertions(+), 3 deletions(-) create mode 100755 t/t2104-update-index-gitfile.sh -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html