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
--

[ message continues ]

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
--

[ message continues ]

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
--

[ message continues ]