All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Ryan Biesemeyer <ryan@yaauie.com>
Cc: git@vger.kernel.org,
	"Matthieu Moy" <Matthieu.Moy@grenoble-inp.fr>,
	"Jonathan Nieder" <jrnieder@gmail.com>,
	"Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>,
	"Jeff King" <peff@peff.net>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: Re: [PATCH v2 3/4] merge: make prepare_to_commit responsible for write_merge_state
Date: Fri, 10 Jan 2014 16:11:11 -0800	[thread overview]
Message-ID: <xmqqlhyn74yo.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1389228344-38813-4-git-send-email-ryan@yaauie.com> (Ryan Biesemeyer's message of "Thu, 9 Jan 2014 00:45:43 +0000")

Ryan Biesemeyer <ryan@yaauie.com> writes:

> When merging, make the prepare-commit-msg hook have access to the merge
> state in order to make decisions about the commit message it is preparing.

What information is currently not available, and if available how
would that help the hook to formulate a better message?

	I am not asking you to answer the question to me in an
	e-mail response. The above is an example of a natural
	question a reader of the above statement would have and
	would wish the log message already answered when the reader
	read it.

> Since `abort_commit` is *only* called after `write_merge_state`, and a
> successful commit *always* calls `drop_save` to clear the saved state, this
> change effectively ensures that the merge state is also available to the
> prepare-commit-msg hook and while the message is being edited.
>
> Signed-off-by: Ryan Biesemeyer <ryan@yaauie.com>
> ---

OK.  The most important part is that this makes sure that these
intermediate state files never remains after the normal codepath
finishes what it does.

You seem to be only interested in prepare-commit-msg hook, but
because of your calling write_merge_state() early, these state files
will persist while we call finish() and they are also visible while
the post-merge hook is run.  While I think it may be a good thing
that the post-merge hook too can view that information, the log
message makes it sound as if it is an unintended side effect of the
change.

>  builtin/merge.c                    |  3 ++-
>  t/t7505-prepare-commit-msg-hook.sh | 21 +++++++++++++++++++++
>  2 files changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/builtin/merge.c b/builtin/merge.c
> index 4941a6c..b7bfc9c 100644
> --- a/builtin/merge.c
> +++ b/builtin/merge.c
> @@ -802,7 +802,6 @@ static void abort_commit(struct commit_list *remoteheads, const char *err_msg)
>  		error("%s", err_msg);
>  	fprintf(stderr,
>  		_("Not committing merge; use 'git commit' to complete the merge.\n"));
> -	write_merge_state(remoteheads);
>  	exit(1);
>  }
>  
> @@ -816,6 +815,8 @@ N_("Please enter a commit message to explain why this merge is necessary,\n"
>  static void prepare_to_commit(struct commit_list *remoteheads)
>  {
>  	struct strbuf msg = STRBUF_INIT;
> +
> +	write_merge_state(remoteheads);
>  	strbuf_addbuf(&msg, &merge_msg);
>  	strbuf_addch(&msg, '\n');
>  	if (0 < option_edit)
> diff --git a/t/t7505-prepare-commit-msg-hook.sh b/t/t7505-prepare-commit-msg-hook.sh
> index 697ecc0..7ccf870 100755
> --- a/t/t7505-prepare-commit-msg-hook.sh
> +++ b/t/t7505-prepare-commit-msg-hook.sh
> @@ -183,4 +183,25 @@ test_expect_success 'with failing hook (merge)' '
>    )
>  '
>  
> +test_expect_success 'should have MERGE_HEAD (merge)' '
> +
> +	git checkout -B other HEAD@{1} &&
> +	echo "more" >> file &&

Style: no SP between the redirection operator and its target, i.e.

	echo more >>file &&

> +	git add file &&
> +	rm -f "$HOOK" &&
> +	git commit -m other &&
> +	git checkout - &&
> +	write_script "$HOOK" <<-EOF &&
> +	if [ -s "$(git rev-parse --git-dir)/MERGE_HEAD" ]; then

Style: no [], and no semicolon to join two lines of control
statement into one, i.e.

	if test -s ...
	then

> +		exit 0
> +	else
> +		exit 1
> +	fi
> +	EOF
> +	git merge other &&
> +	test "`git log -1 --pretty=format:%s`" = "Merge branch '"'"'other'"'"'" &&

Style:

    - After "sh t7505-*.sh v -i" fails for whatever reason, being
      able to inspect the trash directory to see what actually was
      produced is much easier way to debug than having to re-run the
      command with "sh -x" to peek into what the "test" statement is
      getting.

    - $(...) is much easier to read than `...`, but you do not have
      to use either if you follow the above.

i.e.

	git log -1 --format=%s >actual &&
        echo "Merge branch '\''other'\''" >expect &&
        test_cmp expect actual &&

> +	test ! -s "$(git rev-parse --git-dir)/MERGE_HEAD"
> +
> +'
> +
>  test_done

  reply	other threads:[~2014-01-11  0:11 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-08 19:00 [PATCH] merge: make merge state available to prepare-commit-msg hook Ryan Biesemeyer
2014-01-08 19:02 ` Ryan Biesemeyer
2014-01-08 20:06   ` Matthieu Moy
2014-01-08 20:21     ` Ryan Biesemeyer
2014-01-08 20:29       ` Jonathan Nieder
2014-01-08 21:30       ` Matthieu Moy
2014-01-08 22:01         ` Jonathan Nieder
2014-01-09 13:25           ` Matthieu Moy
2014-01-08 19:03 ` Ryan Biesemeyer
2014-01-09  0:45 ` [PATCH v2 0/4] " Ryan Biesemeyer
2014-01-09  0:45   ` [PATCH v2 1/4] t7505: add missing && Ryan Biesemeyer
2014-01-09  0:45   ` [PATCH v2 2/4] t7505: ensure cleanup after hook blocks merge Ryan Biesemeyer
2014-01-09 13:00     ` Matthieu Moy
2014-01-10 23:40       ` Junio C Hamano
2014-01-09  0:45   ` [PATCH v2 3/4] merge: make prepare_to_commit responsible for write_merge_state Ryan Biesemeyer
2014-01-11  0:11     ` Junio C Hamano [this message]
2014-01-11  0:20     ` Junio C Hamano
2014-01-09  0:45   ` [PATCH v2 4/4] merge: drop unused arg from abort_commit method signature Ryan Biesemeyer

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=xmqqlhyn74yo.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=pclouds@gmail.com \
    --cc=peff@peff.net \
    --cc=ryan@yaauie.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.