Shell aliases & paths

Shell aliases & paths

[Eli Barzilay]

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?

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!

Re: Shell aliases & paths

[Jonathan Nieder]

Eli Barzilay wrote:

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

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

Re: Shell aliases & paths

[Eli Barzilay]

On May  4, Jonathan Nieder wrote:
> Eli Barzilay wrote:
> 
> > 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?
> 
> Not that I can see.  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...)


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

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

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!

Re: Shell aliases & paths

[Jonathan Nieder]

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

Re: Shell aliases & paths

[Eli Barzilay]

On May  4, Jonathan Nieder wrote:
> 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. :(

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

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!