Rémi Vanicat <[email protected]> writes: > Marius Vollmer <[email protected]> writes: > >> 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:
I see. Hmm. Previously, the pre-commit-hook would run when hitting 'C-c C-c' after writing the message, and now it should run when hitting 'c', before writing it. As Adam says, this is quite a big change to the commit work flow, since hitting 'c' (or 'cc') used to just switch buffers, and now it runs some hooks that might take some time, produce potentially interesting output, and might even fail. Maybe there can be a new key binding that runs the pre-commit-hook explicitly? > Note also that if emacsclient bother you so much, [...] Well, it seems to have caused a ton of regressions in the way it is used and I have a hunch that it will continue to come back to bite us in the ass for a long time. What about running git twice for a commit? Once to run all the pre- hooks and prepare the commit message, and a second time to actually do the commit, without running any pre-hooks? This seems to produce the commit message in "foo" EDITOR=/bin/cat git commit >foo and "--no-verify" can be used to skip the pre-commit hook on the actual commit, if that is desired. -- --- 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.
