Eli Barzilay wrote:
> On May 4, Jonathan Nieder wrote:
>> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html