Re: git 'new' alias

[Jeff King <peff@peff.net>]

On Thu, Sep 01, 2011 at 09:40:28PM +0200, Matthieu Moy wrote:

> Thiago Farina <tfransosi@gmail.com> writes:
> 
> > Hi,
> >
> > Could we change the 'new' alias in the wiki page,
> >
> > from:
> > new = !sh -c 'git log $1@{1}..$1@{0} "$@"'
> >
> > to:
> > new = !git log $1@{1}..$1@{0} "$@"
> >
> > ?
> 
> Go on. I think I'm the one who added it, and I didn't know $1 and $@
> would work without "sh -c", but I guess my version results in calling
> stg like sh -c "sh -c 'git log ...'" which is a bit overkill ;-).

Hmm. Aren't both of these somewhat wrong?

Git will assume your alias is a shell snippet, append the
space-separated shell-quoted arguments provided to the alias to your
snippet, and then hand the result to the shell.

We can simulate the first one with:

  $ git config alias.one
  !sh -c 'echo $1@{1}..$1@{0} "$@"'

which gives:

  $ git one foo
  @{1}..@{0}

Oops, that's not right. You need a placeholder for $0. So make it:

  $ git config alias.one
  !sh -c 'echo $1@{1}..$1@{0} "$@"' --

and now you get:

  $ git one foo
  foo@{1}..foo@{0} foo

Wait, what's that extra "foo" on the end? I'm not sure of the intent.
Either it is totally superfluous, or perhaps it was meant to pass along
other options, like path limiters. In the former case, you just want:

  !sh -c 'echo $1@{1}..$1@{0}' --

and in the latter case, you actually want to shift off $1 and provide
the rest of the options. Of course, for this particular alias, it so
happens that adding an extra $1 is equivalent to $1@{0}, which is
superfluous but harmless. More on that in a minute.

How about the second one:

  $ git config alias.two
  !echo $1@{1}..$1@{0} "$@"

which yields:

  $ git two foo
  foo@{1}..foo@{0} foo foo

Now we have two extra foos! One is from a superfluous use of "$@", which
is no longer necessary to pass along extra args, since we aren't
invoking a subshell. So we are better off with:

  $ git config alias.two
  !echo $1@{1}..$1@{0}

which yields:

  $ git two foo
  foo@{1}..foo@{0} foo

Better, but we still get our superfluous "foo" at the end. And there's
no way to get rid of it here, since it is appended to our shell snippet.
We can't just shift it away.

So in this particular alias, you can live without the subshell wrapper,
and the final alias.two I mentioned is OK. If you're satisfied with
that, you can stop reading now. I still find the repeated refname a
little hack-ish, though, as it doesn't extend to other aliases
naturally.

You mentioned the ugliness in having the shell call itself. Weep for the
quoting nightmare that is:

  $ git config alias.one
  !sh -c 'echo $1@{1}..$1@{0} "$@"' --

  $ GIT_TRACE=1 git one foo
  trace: exec: 'sh' '-c' 'sh -c '\''echo $1@{1}..$1@{0} "$@"'\'' -- "$@"' 'sh -c '\''echo $1@{1}..$1@{0} "$@"'\'' --' 'foo'

Fortunately, we can do a little better using shell functions. I would
write this as:

  $ git config alias.one
  !f() { r=$1; shift; echo $r@{1}..$r@{0} "$@"; }; f

  $ git one foo
  foo@{1}..foo@{0}

  $ git one foo bar
  foo@{1}..foo@{0} bar

which I think was the original intent (modulo me replacing "git log"
with "echo" for debugging, of course). And if you peek at GIT_TRACE
output, we only invoke a single shell.

Now back to the original complaint: no shell completion. For that, I
would simply add:

  _git_new() {
    __git_complete_revlist
  }

to my .bashrc. Yeah, it's a little more work than having the completion
automatically figure out that "new" takes the same arguments as "git
log", but it works in the general case.

-Peff