On Sun, May 26, 2024 at 04:26:51PM -0700, Junio C Hamano wrote:
> As I keep saying over multiple iterations, the above three bullet
> points stress too much on the minute implementation detail while
> failing to tell readers that the end-user alias receives the rest of
> the command line as arguments.
OK, I can agree that perhaps I've been a bit to fixated on the
addition of "$@" and the mechanics of this. I will propose again with
this trimmed. What I didn't have to help me at the time was the full
command in GIT_TRACE, which I think is probably a more appropriate way
to communicate these details of what's actually hitting the exec
calls.
> Of course the simplest one-liner, if you had the "one" script
> already stored in the file, is to say
So the reason I fell into this, and I wonder how much this plays out
for others too, is that shipping these workflow bits as stand-alone
scripts would mean no !shell tricks required, it's all very logical
and I would never have looked at any of this :) However, when all you
have is a hammer ... since a git config .inc file was needed for other
things, it has been overloaded into essentially being mini
package-manger that avoids having to install additional dependencies;
one-liner shell script at a time :)
> You can do one of two easy things.
>
> $ sh -c 'echo "$1" | grep "$2"' - 1 2
Ok, I think "sh -c" in ! aliases is a bit confusing, personally. You
end up two shells nested deep, and you really have to explain what's
going on with $0; it's very easy to miss.
> $ e(){ echo "$1" | grep "$2"; };e 1 2
This method, which is used elsewhere in the docs as well, I think
makes the most sense. So I've left that in as the example.
-i
