git-send-email and aliases

Hi,

I'm trying to make an alias for 'git send-email' as following but it's not working:

[alias]
	send-email = send-email --no-signed-off-cc --suppress-from

Is it failing because git-send-email is an external command ?

Thanks

"Francis Moreau" <francis.moro@gmail.com> writes:

$ sed -ne '/^alias\.\*/,/^$/p' Documentation/config.txt

On 3/26/07, Junio C Hamano <junkio@cox.net> wrote:

oops sorry. I was so thinking about bash aliases that I didn't take a look to the documentation.

sorry again.

On 3/26/07, Junio C Hamano <junkio@cox.net> wrote:

That said I think it's not really convenient. I'll end up doing:

[aliases]
    my-send-email = send-email --no-signed-off-cc --suppress-from
    my-am = am -3 -s

etc...

Isn't possible to mimic bash alias handling:. From man: "Aliases are not expanded when the shell is not interactive,... "

IOW is it possible for git to know if it has been invoked interactively ?

thanks

"Francis Moreau" <francis.moro@gmail.com> writes:

I do not think so, but I think alias expanding "git foo" while not expanding "git-foo" should not be too hard. You need two extra preparation steps for such a change to be useful, though.

 (1) Build with $(gitexecdir) set to outside the usual $PATH
     (/usr/libexec/git was suggested in the past) to make sure
     we still support that configuration.  Under this model,
     only a handful programs ("git" wrapper itself and "gitk")
     should be installed on user's PATH and everything else goes
     under $(gitexecdir).  The user's interactive session MUST
     run "git foo" and not "git-foo" as bulk of the stuff is now
     outside of $PATH.  Fix any breakage if found (I do not
     expect many, but there might be some problems around object
     transfers, such as git-daemon spawning git-upload-pack, or
     git-push running git-receive-pack on the other end of the
     connection).

 (2) Audit all our scripts so that they run git commands with
     "git-foo" form, not "git foo" form.  As "git" wrapper is
     supposed to add $(gitexecdir) early in the $PATH while it
     runs itself and its subprocesses, they should find the true
     "git-foo" binary even after $(gitexecdir) is set outside of
     the usual $PATH.  Make sure things still work.

After the above two steps is done, we can be confident that the scripts will not be broken even if we allow a user to say something silly like "alias.cat-file = log --stat", as the scripts will never say "git cat-file" to cause the command to be expanded to "git log --stat" (instead they say "git-cat-file", thanks to your audit in step (2)), thusly avoid the confusion.

On Tue, Mar 27, 2007 at 03:29:37AM -0700, Junio C Hamano wrote:

Might it not be easier to simply add a GIT_NOALIAS variable, and set it at the top of all git programs?

-Peff

Jeff King <peff@peff.net> writes:

It might be easier but I do not think that is useful. When git-commit runs the $EDITOR for the commit log message, I think people would expect (if you are using vi) "!!git log" to honor their alias.

On Tue, Mar 27, 2007 at 03:59:19AM -0700, Junio C Hamano wrote:

Then git-commit can unset GIT_NOALIAS when it expects to call into "user" code such as the editor.

A potentially bigger problem with any such scheme is that non-git scripts would have to set GIT_NOALIAS. Not a big deal for new scripts, but it might break old scripts.

-Peff

Jeff King <peff@peff.net> writes:

Surely, but then it is not just a matter of "setting GIT_NOALIAS at the top of all git programs" anymore. You need to audit the code.

You are right. Both GIT_NOALIAS and "write git-foo if you do not want to be affected with alias" would fail that.

On 3/27/07, Junio C Hamano <junkio@cox.net> wrote:

Isn't that too dangerous to rely on the fact that scripts will always use "git-foo" syntax ?

On Mon, Mar 26, 2007 at 11:39:52AM +0200, Francis Moreau wrote:

i remember that if this command exists in git (built-in or script), then the built-in is used, for not breaking any scripts. I think, if you set sm or s-m or something like that, it would work.

Sincerly Nicolas