Hi Jeff,
On Thu, Nov 20, 2008 at 10:20:16AM -0500, Jeff King wrote:
> On Thu, Nov 20, 2008 at 02:09:28PM +0100, SZEDER Gábor wrote:
> Hmm. I am sad that this change has broken somebody's existing workflow.
> OTOH, I'm not convinced that workflow wasn't a little crazy to begin
> with, depending on this undocumented munging.
Well, the docs didn't say that the patch is only removed in verbose
mode (; But I agree with you that this is (was) an undocumented
"feature" that I should not have relied upon.
> > So, what is the/is there a preferred way to always include the diff in
> > the commit message template and get it removed automatically? Are
> > there any workarounds other than revert that commit locally?
>
> How about:
>
> $ cat .git/hooks/prepare-commit-msg
> #!/bin/sh
> git diff --cached >>"$1"
>
> $ cat .git/hooks/commit-msg
> #!/bin/sh
> sed -i '/^diff --git/Q' "$1"
>
> which is more or less the original behavior. The only downside I see is
> that "--no-verify" will turn off the commit-msg hook, but not the
> prepare-commit-msg hook.
Thanks for the tip. Junio's suggestion about '# Everything under this
line is deleted.' could be implemented this way fairly easily (just an
additional echo in prepare-commit-msg, and other pattern in
commit-msg). But 'git commit --no-verify' is indeed a problem.
Although I never use it explicitly, 'git rebase -i' does so.
However.
'git rebase -i' uses 'git commit --no-verify' since c5b09feb (Avoid
update hook during git-rebase --interactive, 2007-12-19) to avoid
squashing commits together when the pre-commit hook fails because of
whitespace errors. But note that at that time the 'git commit'
calls looked like this (after that patch):
$USE_OUTPUT git commit --no-verify -F "$MSG" $EDIT_COMMIT
git commit --no-verify -F "$DOTEST"/message -e
Witness that it's not checked whether 'git commit' succeeded or
failed.
However, nowadays those lines look like this:
$USE_OUTPUT git commit --no-verify $MSG_OPT "$MSG_FILE" $EDIT_COMMIT || failed=t
git commit --no-verify -F "$DOTEST"/message -e || { ...
There is a check for failed 'git commit', so if the pre-commit hook
finds whitespace errors, then 'git commit' will error out, and,
consequently, 'git rebase -i' will error out, too, and commits won't
be squashed accidentaly.
So, I wonder whether those '--no-verify' options are still required in
'git rebase -i'.
Any thoughts?
Thanks,
Gábor
--
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
