From: Junio C Hamano <gitster@pobox.com>
To: Paolo Bonzini <bonzini@gnu.org>
Cc: <git@vger.kernel.org>
Subject: Re: [PATCH] add a pre-merge hook
Date: Wed, 27 Aug 2008 11:02:18 -0700 [thread overview]
Message-ID: <7v63pmqqtx.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <E1KYK3t-0000ZX-3b@fencepost.gnu.org> (Paolo Bonzini's message of "Tue, 27 Aug 2008 14:19:42 +0200")
Paolo Bonzini <bonzini@gnu.org> writes:
> +pre-merge
> +---------
> +
> +This hook is invoked before a merge is attempted. The command
> +line passed to the hook can have multiple parameters. The
> +first parameter is the type of merge, which can be one of
> +"squash" (if --squash was given on the command line), "ff"
> +(fast-forward), "trivial" (trivial in-index merge), "merge"
> +(non-trivial 2-head merge), "octopus" (any other merge). After this
> +there is a "--" argument, followed by the commit SHA1 values for the
> +heads being merged.
I think we should have done something like this for post_merge, not just
"1/0 to show if it is a squash" which was an ill-thought-out hack. Is
there a clean way to fix the interface without breaking existing
post_merge hooks in people's repositories?
> +The hook can interrupt the merge by returning a non-zero
> +status. The default hook checks for a boolean configuration
> +key `branch.<branch-name>.allowmerges`, where `<branch-name>`
> +is the current branch. If the key is false, only squash or
> +fast-forward merges are allowed.
Please call whatever you install from template/hooks--* a "sample", not
"default".
> +static int run_hook(const char *name, struct commit_list *heads, ...)
> {
> + ...
> + if (heads) {
> + argv[i] = "--";
> + first_remote_head = i + 1;
> + for (; heads; heads = heads->next)
> + argv[++i] = xstrdup(sha1_to_hex(heads->item->object.sha1));
> + argv[++i] = NULL;
> + } else
> + first_remote_head = i;
Making this function varargs is fine, but this heads==NULL condition needs
some explanation.
If it is primarily a hack to support calling post-merge with an non-object
name "0" or "1", probably it will be _much_ cleaner to make this a
separate function that does not know anything about post-merge calling
convention (it can share the boilerplate parts such as "hook.no_stdin = 1"
with the function that calls post-merge, of course).
> +static int run_pre_merge_hook(const char *kind)
> +{
> + return run_hook("pre-merge", remoteheads,
> + squash ? "squash" : kind, "--", NULL);
> }
remoteheads is a commit_list, you have the name of the hook and kind, so
this extra "--" is only for run_hook() hackery to distinguish between the
callers to post-merge and the callers to new pre-merge?
The general idea to add "pre-merge" hook may be sound, but the run_hook()
implementation looks quite unclean.
next prev parent reply other threads:[~2008-08-27 18:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-21 12:09 [PATCH] add a pre-merge hook Paolo Bonzini
2008-08-27 12:19 ` Paolo Bonzini
2008-08-27 18:02 ` Junio C Hamano [this message]
2008-08-27 20:05 ` Paolo Bonzini
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=7v63pmqqtx.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=bonzini@gnu.org \
--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).