Shell aliases & paths

AFAICT, a shell command alias (one that starts with a "!") is executed from the repository root, but to make things worse it looks like there is no way to tell which directory it was executed from. If this is correct, then these aliases are useless for anything that need to accept relative paths. Is there something obvious that I'm missing?

Eli Barzilay wrote:

Not that I can see. Maybe a new GIT_PATHNAME_PREFIX environment variable would help.

If we were starting from scratch, it might be nice to make aliases suppress the chdir to toplevel. Unfortunately, that would probably break some existing aliases. Another possibility would be to use some alternative convention (like [alias] foo = "# bar") to suppress the repository search. At that point, why not just add a git-foo script to $PATH? (‘git foo’ will still call it.)

Hope that helps, Jonathan

On May  4, Jonathan Nieder wrote:

Yeah, I was searching the environment for something like that, and was surprised when I didn't find any shred of the original path in there. (In any case, I'd like to see something like that, although it's too late for me to use it since I need a solution that works now...)

The same can be said on all shell aliases, no?

FWIW, I find these aliases more convenient in having "extensions" work for other people -- ie, it's easier to say "here's some text, dump it in your ~/.gitconfig" than it is to explain where some script should be added and how ("put the text in a git-foo file, make sure to chmod +x it, put that in your $PATH, you do have your own bin directory, right?").

(But the disclaimer here is that I have a very narrow point of view.)

Eli Barzilay wrote:

Care to write a patch?  But yeah, sounds like for now you’re screwed. :(

True shell aliases have the advantage of not being inherited by subprocesses, so they can be made to apply in interactive shells only and avoid breaking scripts. Similarly, if you write an alias in .git/config, it does not pollute the command namespace for other repositories. I am not sure how much people take advantage of this.

Aliases also do the work to detect a git repository and set GIT_DIR, which I guess some people would want; and the non-! aliases avoid forking a new process.

Hmm, maybe teaching git to respect a core.toolpath setting would help in some situations[1]. I am thinking of two scenarios:

 A. To simplify its installation process, such-and-such git extension
    does not require access to a directory on the user’s $PATH.
    Instead, you just extract it wherever (~/opt/the-extension, say)
    and then add “[core] toolpath = "~/opt/the-extension"” to your
    .gitconfig.

 B. On an insane platform, the user might want git to look for the
    standard tools in /usr/sfw or something instead of /usr/bin or
    /usr/xpg4/bin.  Making this a run-time configurable setting gives
    the user a chance to override a misguided system-wide choice or
    experiment with what works best.

I don’t fall into either of these categories, so I can’t say whether it would be actually helpful, though.

Thanks for the explanations. Jonathan

[1] http://thread.gmane.org/gmane.comp.version-control.git/121063/focus=121085

On May  4, Jonathan Nieder wrote:

Right, I already need to move to a script instead, so less motivation. (And a ssubversion->git move certainly filled my quota of doing non-work things...)