On Fri, Aug 30, 2013 at 02:50:57PM +0200, Rémi Vanicat wrote: > Marius Vollmer <[email protected]> writes: > > > Jonas Bernoulli <[email protected]> writes: > > > >> Some of the drawbacks of the new workflow will vanish after making overdue > >> changes elsewhere. But some drawbacks are inherent to the use of > >> emacsclient. > > > > Using emacsclient strikes me as wrong. If I understand things right > > from reading this list, you want Git to prepare the content of the > > commit message. Couldn't that be done by piping "git commit --dry-run" > > into the buffer? > > git commit --dry-run don't run git's pre-commit-hook nor > prepare-commit-msg: > > % ln -s /bin/false .git/hooks/pre-commit > % git commit > % git commit --dry-run > # Sur la branche master > # Modifications qui seront validées : > [...] > > You can see that running git commit just fail because the pre-commit > failed, but dry-run do print its result.
Is it really necessary to run pre-commit-hook whilst preparing a commit log buffer? Normally that hook is used for validation tests, e.g. checking code style or running unit tests, right? So it's enough for those to be run when the real commit happens. Obviously prepare-commit-msg needs to be run, and it's arguably a missing feature in git that commit --dry-run can't run it, but presumably it's trivial to work around that shortcoming by running it manually? > Note also that if emacsclient bother you so much, there is already what > is needed for magit to not run it: > > (setq magit-emacsclient-executable nil) Really? "git grep magit-emacsclient-executable" in my magit repo yields no matches, nor does my running emacs have any awareness of that variable. -- --- You received this message because you are subscribed to the Google Groups "magit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
