Re: Shell aliases & paths

From: Jonathan Nieder <jrnieder@gmail.com>
Date: May 4, 2010, 22:30 UTC
Message-ID: <20100504223028.GA15548@progeny.tock>
In-Reply-To: <19424.36914.867693.327548@winooski.ccs.neu.edu>

Eli Barzilay wrote:

> On May  4, Jonathan Nieder wrote:

Show 7 quoted lines

>> Maybe a new GIT_PATHNAME_PREFIX environment
>> variable would help.
>
> 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...)

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

>> At that point, why not just add a git-foo script to $PATH?  (‘git
>> foo’ will still call it.)
>
> The same can be said on all shell aliases, no?

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.

> 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

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