Sven Strickroth <[email protected]> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
