On Thu, Sep 01, 2011 at 09:40:28PM +0200, Matthieu Moy wrote:
> Thiago Farina <tfransosi@xxxxxxxxx> 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
--
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