git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeffrey Middleton <jefromi@gmail.com>
To: git@vger.kernel.org
Subject: Re: [RFC/PATCH] merge: honor prepare-commit-msg hook
Date: Tue, 8 Mar 2011 18:16:34 -0600	[thread overview]
Message-ID: <AANLkTimqxNNJ7ezBYC8V_pW5=HB1md1xVrnKFV8sVBue@mail.gmail.com> (raw)

I'd like to add a voice to the support for calling the
prepare-commit-msg and post-commit hooks during a merge.

Reading the documentation, it seems like surely prepare-commit-msg
would be called: the description of the hook mentions that the second
argument might be "merge". The sample hook (also mentioned there)
targets only merge commits, but happens to work because it's designed
to only have an effect if there is a "Conflicts:" section, which
therefore means the user is committing manually. Another possible
merge-related use case for the hook would be intelligently rewriting
the subject, e.g. to canonicalize remote names in integration-style
merges.  If y'all don't agree, I'd suggest modifying the documentation
to clarify that the hook is only called for manually-committed merges.

My instinct is that post-commit makes sense too - if you want to print
some extra information after a commit is recorded, why should it just
be non-merges?

(and just in case, this is a reply to an old thread, including a
proposed patch:
http://thread.gmane.org/gmane.comp.version-control.git/151297/ )

Jeffrey

Junio C Hamano <gitster <at> pobox.com> writes:
> Jay Soffian <jaysoffian <at> gmail.com> writes:
> > ---
> > I couldn't figure out why my prepare-commit-msg wasn't being honored
> > by git merge.
>
> It has been that way from day one, it appears.
>
> The bypassing of pre-commit hook was and remains to be a conscious design
> decision.  When you are pulling from your contributors who may have
> objectionable contents that you have to merge, the damage is already
> done; you _could_ yell at them to fix their branch and re-pull in theory,
> but that wouldn't work very well in practice.
>
> On the other hand, I think letting people use prepare-commit-msg for
> merges might  make sense.  Indeed, "git commit" is prepared to call
> prepare-commit-msg telling the hook that it is concluding a merge, when
> your "git merge" stopped due to a conflict (or you stopped it from making
> a new commit with --no-commit).
>
> I don't know about the other hooks "git commit" normally calls.  Both
> "commit-msg" and "post-commit" may make sense, but I don't care too deeply
> either way---I don't care too deeply for pre-commit either ;-).

             reply	other threads:[~2011-03-09  0:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-09  0:16 Jeffrey Middleton [this message]
2011-03-09 22:50 ` [RFC/PATCH] merge: honor prepare-commit-msg hook Jay Soffian
  -- strict thread matches above, loose matches on Subject: below --
2010-07-20  4:29 Jay Soffian
2010-07-22  0:14 ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='AANLkTimqxNNJ7ezBYC8V_pW5=HB1md1xVrnKFV8sVBue@mail.gmail.com' \
    --to=jefromi@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).