public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed

From: Junio C Hamano <gitster@pobox•com>
To: Sven Strickroth <sven@cs-ware•de>
Cc: Git List <git@vger•kernel.org>
Subject: Re: [PATCH] Also read SQUASH_MSG if a conflict on a merge squash occurred
Date: Tue, 08 Mar 2016 10:32:51 -0800	[thread overview]
Message-ID: <xmqq60wwlt0s.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <56DE5272.2080009@cs-ware.de> (Sven Strickroth's message of "Tue, 8 Mar 2016 05:17:54 +0100")

Sven Strickroth <sven@cs-ware•de> writes:

> Subject: Re: [PATCH] Also read SQUASH_MSG if a conflict on a merge squash occurred

A reader sees this line in the output of "git shortlog --no-merges";
does it sufficiently tell her which Git subcommand is affected by
this change, if this is a bugfix or a new feature, i.e. enough for
her to decide how important the change is?

We often prefix our log message with the name of the area followed
by a colon and describe the purpose of the change, not the means how
the objective is achieved, e.g.

    Subject: [PATCH] commit: do not lose SQUASH_MSG contents

    When concluding a conflicted "git merge --squash", the command
    failed to read SQUASH_MSG that was prepared by "git merge", and
    showed only the "# Conflicts:" list of conflicted paths.

> diff --git a/builtin/commit.c b/builtin/commit.c
> index d054f84..0405d68 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -729,6 +729,12 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
>  		if (strbuf_read_file(&sb, git_path_merge_msg(), 0) < 0)
>  			die_errno(_("could not read MERGE_MSG"));
>  		hook_arg1 = "merge";
> +		/* append SQUASH_MSG here if it exists and a merge --squash was originally performed */

	/*
         * Our multi-line comment reads more like
         * this.  That is, the first slash-asterisk is on its
         * own line, so is the last asterisk-slash.
         */

> +		if (!stat(git_path_squash_msg(), &statbuf)) {
> +			if (strbuf_read_file(&sb, git_path_squash_msg(), 0) < 0)
> +				die_errno(_("could not read SQUASH_MSG"));
> +			hook_arg1 = "squash";
> +		}
>  	} else if (!stat(git_path_squash_msg(), &statbuf)) {
>  		if (strbuf_read_file(&sb, git_path_squash_msg(), 0) < 0)
>  			die_errno(_("could not read SQUASH_MSG"));

This reads MERGE_MSG first and then SQUASH_MSG; is that what we
really want?  When you are resolving a conflicted rebase, you would
see the original log message and then conflicts section.  What is in
the SQUASH_MSG is the moral equivalent of the "original log message"
but in a less summarized form, so I suspect that the list of conflicts
should come to end.

The duplicated code to read the same file bothers me somewhat.

I wondered if it makes the result easier to follow (and easier to
update) if this part of the code is restructured like this:

	if (file_exists(git_path_merge_msg()) ||
            file_exists(git_path_squash_msg())) {
	    if (file_exists(git_path_squash_msg())) {
		read SQUASH_MSG;
	    }
            if (file_exists(git_path_merge_msg()))
            	read MERGE_MSG;
	    }
            hook_arg1 = "merge";
	}

but I am not sure if that structure is better.

Thanks.

next prev parent reply	other threads:[~2016-03-08 18:32 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-05 10:38 Commit message not helpful after merge squash with conflicts Sven Strickroth
2016-03-08  4:17 ` [PATCH] Also read SQUASH_MSG if a conflict on a merge squash occurred Sven Strickroth
2016-03-08 18:32   ` Junio C Hamano [this message]
2016-03-08 18:49     ` Sven Strickroth
2016-03-08 18:51       ` Junio C Hamano
2016-03-08 19:03     ` [PATCH] commit: do not lose SQUASH_MSG contents Sven Strickroth
2016-03-09 18:04     ` [PATCH] Also read SQUASH_MSG if a conflict on a merge squash occurred Junio C Hamano
2016-03-09 20:24       ` Junio C Hamano
2016-03-13 18:39         ` [PATCH] commit: do not lose SQUASH_MSG contents Sven Strickroth
2016-03-14 18:19           ` Junio C Hamano
2016-03-14 20:19             ` Junio C Hamano
2016-03-21 22:29               ` Sven Strickroth
2016-03-21 22:34                 ` 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=xmqq60wwlt0s.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox$(echo .)com \
    --cc=git@vger$(echo .)kernel.org \
    --cc=sven@cs-ware$(echo .)de \
    /path/to/YOUR_REPLY

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox