[PATCH v2 0/2] Support relative .git file in a submodule

[Brad King <brad.king@kitware.com>]

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