git alias always chdir to top

git alias always chdir to top

[Pete Wyckoff]

I have a git alias that takes a relative file name argument,
and would like to know from where in the tree it was invoked,
especially if inside a subdirectory of the git tree.

Consider .git/config:

    [alias]
	pwd = !/bin/pwd

Then a git tree:

    /home/me
	topdir/
	    .git/
	    subdir/
		subdir-y.c
	    topdir-x.c

Then inside /home/me/topdir, all is well:

    $ pwd
    /home/me/topdir
    $ git pwd
    /home/me/topdir

But inside /home/me/topdir/subdir, the pwd alias is invoked in the wrong
dir:

    $ pwd
    /home/me/topdir/subdir
    $ git pwd
    /home/me/topdir

The implication of this is that I call an alias command like:

    $ pwd
    /home/me/topdir/subdir
    $ git myalias subdir-y.c
    myalias: No such file subdir-y.c

It looks like handle_alias() uses setup_git_directory_gently() to
find the .git, which chdir()s up until it gets there.  Is there a
way to do this without changing the process current working
directory instead?  I could even handle an environment variable
saving the original cwd, but that's ickier.

		-- Pete

Re: git alias always chdir to top

[Jeff King]

On Wed, Dec 03, 2008 at 11:08:52AM -0500, Pete Wyckoff wrote:

> It looks like handle_alias() uses setup_git_directory_gently() to
> find the .git, which chdir()s up until it gets there.  Is there a
> way to do this without changing the process current working
> directory instead?  I could even handle an environment variable
> saving the original cwd, but that's ickier.

There has been some discussion of refactoring the setup to _not_ do that
chdir until later, which should fix your problem. And other problems,
too, since aliases can get confused about whether or not we're in a
worktree (try "git config alias.st status && cd .git && git st") as a
result of the startup sequence.  Ideally the _only_ thing to happen
before running an alias would be to look at the config to see how to run
the alias, and everything else would be "as if" you had just run the
alias manually.

So no, there's no way to do it correctly right now. The git commands
internally do know the original prefix, but I don't think it is exposed
via the environment.

I hope this will get fixed eventually, but refactoring this code is
unpleasant enough and I have been busy enough that it hasn't happened
yet. You are of course welcome to volunteer. ;)

-Peff

Re: git alias always chdir to top

[Pete Wyckoff]

peff@peff.net wrote on Thu, 04 Dec 2008 07:34 -0500:
> On Wed, Dec 03, 2008 at 11:08:52AM -0500, Pete Wyckoff wrote:
> 
> > It looks like handle_alias() uses setup_git_directory_gently() to
> > find the .git, which chdir()s up until it gets there.  Is there a
> > way to do this without changing the process current working
> > directory instead?  I could even handle an environment variable
> > saving the original cwd, but that's ickier.
> 
> There has been some discussion of refactoring the setup to _not_ do that
> chdir until later, which should fix your problem. And other problems,
> too, since aliases can get confused about whether or not we're in a
> worktree (try "git config alias.st status && cd .git && git st") as a
> result of the startup sequence.  Ideally the _only_ thing to happen
> before running an alias would be to look at the config to see how to run
> the alias, and everything else would be "as if" you had just run the
> alias manually.
> 
> So no, there's no way to do it correctly right now. The git commands
> internally do know the original prefix, but I don't think it is exposed
> via the environment.
> 
> I hope this will get fixed eventually, but refactoring this code is
> unpleasant enough and I have been busy enough that it hasn't happened
> yet. You are of course welcome to volunteer. ;)

Thanks for these comments.  I missed the discussion about
refactoring to move the chdir around.

In my particular case, since the only usage of this particular git
alias is by another script, I can get away with passing the full
path name and making some assumptions about the caller.

Point taken that it would be good to clean up the alias code path
so that this issue doesn't even arise in the first place.

		-- Pete