[RFC PATCH 0/3] git-merge: update default commit message

[RFC PATCH 0/3] git-merge: update default commit message

[i.Dark_Templar]

This series of patches updates default commit message for git-merge command.

First patch adds alternative commit message formatting where
each merged object is printed on new line and adds configuration option to enable it.

New format may look good for merges with a lot of objects, but
for merge with just one object old format may still look better.
To be able to use both formats, new format type 'autoselect' is added
in patch 2, and configuration option for format selection is reworked.

Patch 3 changes default message formatting to 'autoselect' introduced
in patch 2, thus changing default behaviour of git.

i.Dark_Templar (3):
  git-merge: add option to format default message using multiple lines
  Add merge commit message type autoselect logic
  Enable merge commit message type autoselect logic by default

 Documentation/config/fmt-merge-msg.txt |  13 +++
 builtin/fmt-merge-msg.c                | 127 ++++++++++++++++++++++++-
 2 files changed, 138 insertions(+), 2 deletions(-)

--
2.24.1

[RFC PATCH 1/3] git-merge: add option to format default message using multiple lines

[i.Dark_Templar]

If a lot of objects is merged at once, default commit message
could become one very long line, which might be inconvenient to read.
This change implements an option to change default autogenerated message
so it'd take multiple lines, but each line wouldn't be long.

An artificial example.

Original merge commit message:
    Merge branch 'branch_with_some_long_name_1', remote-tracking branch 'clone/remote_branch_with_some_name', tags 'some_tag' and 'some_other_tag'; commit 'ae46a39cead2b42282abce725e90b561c06e94ba'; commit '33d0281e0eeb2a5e9907ebedc230e28c46865092' into merge7

Multiline merge commit message:
    Merge into merge8:
    branch 'branch_with_some_long_name_1'
    remote-tracking branch 'clone/remote_branch_with_some_name'
    tag 'some_tag'
    tag 'some_other_tag'
    commit 'ae46a39cead2b42282abce725e90b561c06e94ba'
    commit '33d0281e0eeb2a5e9907ebedc230e28c46865092'

Signed-off-by: i.Dark_Templar <darktemplar@dark-templar-archives.net>
---
 Documentation/config/fmt-merge-msg.txt |  6 +++
 builtin/fmt-merge-msg.c                | 66 +++++++++++++++++++++++++-
 2 files changed, 70 insertions(+), 2 deletions(-)

diff --git a/Documentation/config/fmt-merge-msg.txt b/Documentation/config/fmt-merge-msg.txt
index c73cfa90b7..8c12540fa7 100644
--- a/Documentation/config/fmt-merge-msg.txt
+++ b/Documentation/config/fmt-merge-msg.txt
@@ -8,3 +8,9 @@ merge.log::
 	most the specified number of one-line descriptions from the
 	actual commits that are being merged.  Defaults to false, and
 	true is a synonym for 20.
+
+merge.multilineMessage::
+	Make default merge commit message multiline. Every merged object
+	will be written using new line. This should ensure that
+	commit message wouldn't become one very long line when
+	there are a lot of merged objects.
diff --git a/builtin/fmt-merge-msg.c b/builtin/fmt-merge-msg.c
index 05a92c59d8..93d44b59d9 100644
--- a/builtin/fmt-merge-msg.c
+++ b/builtin/fmt-merge-msg.c
@@ -20,6 +20,7 @@ static const char * const fmt_merge_msg_usage[] = {
 };
 
 static int use_branch_desc;
+static int use_multiline_default_message = 0;
 
 int fmt_merge_msg_config(const char *key, const char *value, void *cb)
 {
@@ -32,6 +33,8 @@ int fmt_merge_msg_config(const char *key, const char *value, void *cb)
 			merge_log_config = DEFAULT_MERGE_LOG_LEN;
 	} else if (!strcmp(key, "merge.branchdesc")) {
 		use_branch_desc = git_config_bool(key, value);
+	} else if (!strcmp(key, "merge.multilinemessage")) {
+		use_multiline_default_message = git_config_bool(key, value);
 	} else {
 		return git_default_config(key, value, cb);
 	}
@@ -467,6 +470,61 @@ static void fmt_merge_msg_title(struct strbuf *out,
 		strbuf_addf(out, " into %s\n", current_branch);
 }
 
+static void fmt_merge_msg_title_multiline(struct strbuf *out,
+				const char *current_branch)
+{
+	int i = 0;
+	int j = 0;
+
+	if (!strcmp("master", current_branch))
+		strbuf_addstr(out, "Merge:\n");
+	else
+		strbuf_addf(out, "Merge into %s:\n", current_branch);
+
+	for (i = 0; i < srcs.nr; i++) {
+		struct src_data *src_data = srcs.items[i].util;
+		int add_origin = 0;
+
+		if (src_data->head_status == 1) {
+			strbuf_addf(out, "%s\n", srcs.items[i].string);
+			continue;
+		}
+
+		add_origin = strcmp(".", srcs.items[i].string);
+
+		if (src_data->head_status == 3) {
+			if (!add_origin)
+				strbuf_addstr(out, "HEAD\n");
+			else
+				strbuf_addf(out, "HEAD of %s\n", srcs.items[i].string);
+		}
+		for (j = 0; j < src_data->branch.nr; j++) {
+			if (!add_origin)
+				strbuf_addf(out, "branch %s\n", src_data->branch.items[j].string);
+			else
+				strbuf_addf(out, "branch %s of %s\n", src_data->branch.items[j].string, srcs.items[i].string);
+		}
+		for (j = 0; j < src_data->r_branch.nr; j++) {
+			if (!add_origin)
+				strbuf_addf(out, "remote-tracking branch %s\n", src_data->r_branch.items[j].string);
+			else
+				strbuf_addf(out, "remote-tracking branch %s of %s\n", src_data->r_branch.items[j].string, srcs.items[i].string);
+		}
+		for (j = 0; j < src_data->tag.nr; j++) {
+			if (!add_origin)
+				strbuf_addf(out, "tag %s\n", src_data->tag.items[j].string);
+			else
+				strbuf_addf(out, "tag %s of %s\n", src_data->tag.items[j].string, srcs.items[i].string);
+		}
+		for (j = 0; j < src_data->generic.nr; j++) {
+			if (!add_origin)
+				strbuf_addf(out, "commit %s\n", src_data->generic.items[j].string);
+			else
+				strbuf_addf(out, "commit %s of %s\n", src_data->generic.items[j].string, srcs.items[i].string);
+		}
+	}
+}
+
 static void fmt_tag_signature(struct strbuf *tagbuf,
 			      struct strbuf *sig,
 			      const char *buf,
@@ -634,8 +692,12 @@ int fmt_merge_msg(struct strbuf *in, struct strbuf *out,
 			die("error in line %d: %.*s", i, len, p);
 	}
 
-	if (opts->add_title && srcs.nr)
-		fmt_merge_msg_title(out, current_branch);
+	if (opts->add_title && srcs.nr) {
+		if (!use_multiline_default_message)
+			fmt_merge_msg_title(out, current_branch);
+		else
+			fmt_merge_msg_title_multiline(out, current_branch);
+	}
 
 	if (origins.nr)
 		fmt_merge_msg_sigs(out);
-- 
2.24.1

[RFC PATCH 2/3] Add merge commit message type autoselect logic

[i.Dark_Templar]

Signed-off-by: i.Dark_Templar <darktemplar@dark-templar-archives.net>
---
 Documentation/config/fmt-merge-msg.txt | 17 ++++--
 builtin/fmt-merge-msg.c                | 71 ++++++++++++++++++++++++--
 2 files changed, 78 insertions(+), 10 deletions(-)

diff --git a/Documentation/config/fmt-merge-msg.txt b/Documentation/config/fmt-merge-msg.txt
index 8c12540fa7..3829095222 100644
--- a/Documentation/config/fmt-merge-msg.txt
+++ b/Documentation/config/fmt-merge-msg.txt
@@ -9,8 +9,15 @@ merge.log::
 	actual commits that are being merged.  Defaults to false, and
 	true is a synonym for 20.
 
-merge.multilineMessage::
-	Make default merge commit message multiline. Every merged object
-	will be written using new line. This should ensure that
-	commit message wouldn't become one very long line when
-	there are a lot of merged objects.
+merge.messageType::
+	Configure default merge commit message type. `original` is used
+	if no value or an invalid value is set.
+	+
+	* `original` keeps old merge commit message format which takes only one line.
+	* `multiline` switches merge commit message to multiline mode. Every merged object
+	will be written using new line. This should ensure that commit message
+	wouldn't become one very long line when there are a lot of merged objects.
+	* `autoselect`, as it's name implies, selects one of following types
+	using arbitrary logic. Currently it selects `original` mode for merge
+	with only one additional object, otherwise switching to `multiline` mode,
+	but this behaviour may be changed in future without any notice.
diff --git a/builtin/fmt-merge-msg.c b/builtin/fmt-merge-msg.c
index 93d44b59d9..0bc6ce5b05 100644
--- a/builtin/fmt-merge-msg.c
+++ b/builtin/fmt-merge-msg.c
@@ -14,13 +14,20 @@
 #include "repository.h"
 #include "commit-reach.h"
 
+enum message_format {
+	MESSAGE_FORMAT_ORIGINAL = 0,
+	MESSAGE_FORMAT_MULTILINE = 1,
+	MESSAGE_FORMAT_AUTOSELECT = 2,
+	MESSAGE_FORMAT_DEFAULT = MESSAGE_FORMAT_ORIGINAL
+};
+
 static const char * const fmt_merge_msg_usage[] = {
 	N_("git fmt-merge-msg [-m <message>] [--log[=<n>] | --no-log] [--file <file>]"),
 	NULL
 };
 
 static int use_branch_desc;
-static int use_multiline_default_message = 0;
+static enum message_format default_message_format = MESSAGE_FORMAT_DEFAULT;
 
 int fmt_merge_msg_config(const char *key, const char *value, void *cb)
 {
@@ -33,8 +40,16 @@ int fmt_merge_msg_config(const char *key, const char *value, void *cb)
 			merge_log_config = DEFAULT_MERGE_LOG_LEN;
 	} else if (!strcmp(key, "merge.branchdesc")) {
 		use_branch_desc = git_config_bool(key, value);
-	} else if (!strcmp(key, "merge.multilinemessage")) {
-		use_multiline_default_message = git_config_bool(key, value);
+	} else if (!strcmp(key, "merge.messagetype")) {
+		if (!value)
+			return config_error_nonbool(key);
+
+		if (!strcmp(value, "autoselect"))
+			default_message_format = MESSAGE_FORMAT_AUTOSELECT;
+		else if (!strcmp(value, "original"))
+			default_message_format = MESSAGE_FORMAT_ORIGINAL;
+		else if (!strcmp(value, "multiline"))
+			default_message_format = MESSAGE_FORMAT_MULTILINE;
 	} else {
 		return git_default_config(key, value, cb);
 	}
@@ -525,6 +540,43 @@ static void fmt_merge_msg_title_multiline(struct strbuf *out,
 	}
 }
 
+static void fmt_merge_msg_title_autoselect(struct strbuf *out,
+				const char *current_branch)
+{
+	int i = 0;
+	int j = 0;
+	int objects_count = 0;
+
+	for (i = 0; i < srcs.nr; i++) {
+		struct src_data *src_data = srcs.items[i].util;
+
+		if (src_data->head_status == 1) {
+			++objects_count;
+			continue;
+		}
+		if (src_data->head_status == 3) {
+			++objects_count;
+		}
+		for (j = 0; j < src_data->branch.nr; j++) {
+			++objects_count;
+		}
+		for (j = 0; j < src_data->r_branch.nr; j++) {
+			++objects_count;
+		}
+		for (j = 0; j < src_data->tag.nr; j++) {
+			++objects_count;
+		}
+		for (j = 0; j < src_data->generic.nr; j++) {
+			++objects_count;
+		}
+	}
+
+	if (objects_count > 1)
+		fmt_merge_msg_title_multiline(out, current_branch);
+	else
+		fmt_merge_msg_title(out, current_branch);
+}
+
 static void fmt_tag_signature(struct strbuf *tagbuf,
 			      struct strbuf *sig,
 			      const char *buf,
@@ -693,10 +745,19 @@ int fmt_merge_msg(struct strbuf *in, struct strbuf *out,
 	}
 
 	if (opts->add_title && srcs.nr) {
-		if (!use_multiline_default_message)
+		switch (default_message_format) {
+		case MESSAGE_FORMAT_ORIGINAL:
 			fmt_merge_msg_title(out, current_branch);
-		else
+			break;
+		case MESSAGE_FORMAT_MULTILINE:
 			fmt_merge_msg_title_multiline(out, current_branch);
+			break;
+		case MESSAGE_FORMAT_AUTOSELECT:
+			fmt_merge_msg_title_autoselect(out, current_branch);
+			break;
+		default:
+			BUG("merge.messagetype value is not properly processed: %d", (int) default_message_format);
+		}
 	}
 
 	if (origins.nr)
-- 
2.24.1

[RFC PATCH 3/3] Enable merge commit message type autoselect logic by default

[i.Dark_Templar]

Signed-off-by: i.Dark_Templar <darktemplar@dark-templar-archives.net>
---
 Documentation/config/fmt-merge-msg.txt | 2 +-
 builtin/fmt-merge-msg.c                | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/config/fmt-merge-msg.txt b/Documentation/config/fmt-merge-msg.txt
index 3829095222..acd998cca8 100644
--- a/Documentation/config/fmt-merge-msg.txt
+++ b/Documentation/config/fmt-merge-msg.txt
@@ -10,7 +10,7 @@ merge.log::
 	true is a synonym for 20.
 
 merge.messageType::
-	Configure default merge commit message type. `original` is used
+	Configure default merge commit message type. `autoselect` is used
 	if no value or an invalid value is set.
 	+
 	* `original` keeps old merge commit message format which takes only one line.
diff --git a/builtin/fmt-merge-msg.c b/builtin/fmt-merge-msg.c
index 0bc6ce5b05..8fa39030d3 100644
--- a/builtin/fmt-merge-msg.c
+++ b/builtin/fmt-merge-msg.c
@@ -18,7 +18,7 @@ enum message_format {
 	MESSAGE_FORMAT_ORIGINAL = 0,
 	MESSAGE_FORMAT_MULTILINE = 1,
 	MESSAGE_FORMAT_AUTOSELECT = 2,
-	MESSAGE_FORMAT_DEFAULT = MESSAGE_FORMAT_ORIGINAL
+	MESSAGE_FORMAT_DEFAULT = MESSAGE_FORMAT_AUTOSELECT
 };
 
 static const char * const fmt_merge_msg_usage[] = {
-- 
2.24.1

Re: [RFC PATCH 1/3] git-merge: add option to format default message using multiple lines

[Junio C Hamano]

"i.Dark_Templar" <darktemplar@dark-templar-archives.net> writes:

> If a lot of objects is merged at once, default commit message
> could become one very long line, which might be inconvenient to read.
> This change implements an option to change default autogenerated message
> so it'd take multiple lines, but each line wouldn't be long.
> 
> An artificial example.
>
> Original merge commit message:
>     Merge branch 'branch_with_some_long_name_1', remote-tracking branch 'clone/remote_branch_with_some_name', tags 'some_tag' and 'some_other_tag'; commit 'ae46a39cead2b42282abce725e90b561c06e94ba'; commit '33d0281e0eeb2a5e9907ebedc230e28c46865092' into merge7
>
> Multiline merge commit message:
>     Merge into merge8:
>     branch 'branch_with_some_long_name_1'
>     remote-tracking branch 'clone/remote_branch_with_some_name'
>     tag 'some_tag'
>     tag 'some_other_tag'
>     commit 'ae46a39cead2b42282abce725e90b561c06e94ba'
>     commit '33d0281e0eeb2a5e9907ebedc230e28c46865092'


How would these commits appear in the "git shorlog" output?  Losing
some information is OK (after all, you are making the 'title' of the
merge commit less crowded to prefer 'simpler' summary in exchange),
but you'd need to strike a good balance what to discard.  Is the
fact that the name of branch that got some unspecified new things
was 'merge8' the most important thing to convey?

If you make the commit 'title' a short one-line summary, you MUST
have a blank line after that line.  Otherwise, the 'where does the
title of this commit object end?' logic will helpfully merge all the
lines in the first paragraph (i.e. up to the first blank line) into
one long line, defeating your effort to make the summary simpler by
losing details.  That is:

    Merge 6 commits into merge8

    branch 'branch_with_some_long_name_1'
    remote-tracking ...
    ...

That's it for the 'mechanics', i.e. a discussion about how a good
design of this 'feature' should look like.

About the feature itself, I am not sure.  Even though I admit I was
the one who invented octupus merges, and it does make the history
look "pretty" in gitk when used judiciously, its practical benefit
over repeated pairwise merges is doubtful.  Besides, it makes
bisection less efficient.  So from that point of view, I am not sure
if we want a feature to encourage creation of more octopus merges.

I haven't read the code yet---I usually don't before figuring out if
the feature and its design makes sense---so I have no comment on the
actual change at this moment.  I may send a separate review message
later.

Thanks.

Re: [RFC PATCH 1/3] git-merge: add option to format default message using multiple lines

[i.Dark_Templar]

09.02.2020 20:44, Junio C Hamano пишет:
> "i.Dark_Templar" <darktemplar@dark-templar-archives.net> writes:
> 
>> If a lot of objects is merged at once, default commit message
>> could become one very long line, which might be inconvenient to read.
>> This change implements an option to change default autogenerated message
>> so it'd take multiple lines, but each line wouldn't be long.
>>
>> An artificial example.
>>
>> Original merge commit message:
>>     Merge branch 'branch_with_some_long_name_1', remote-tracking branch 'clone/remote_branch_with_some_name', tags 'some_tag' and 'some_other_tag'; commit 'ae46a39cead2b42282abce725e90b561c06e94ba'; commit '33d0281e0eeb2a5e9907ebedc230e28c46865092' into merge7
>>
>> Multiline merge commit message:
>>     Merge into merge8:
>>     branch 'branch_with_some_long_name_1'
>>     remote-tracking branch 'clone/remote_branch_with_some_name'
>>     tag 'some_tag'
>>     tag 'some_other_tag'
>>     commit 'ae46a39cead2b42282abce725e90b561c06e94ba'
>>     commit '33d0281e0eeb2a5e9907ebedc230e28c46865092'
> 
> 
> How would these commits appear in the "git shorlog" output?  Losing
> some information is OK (after all, you are making the 'title' of the
> merge commit less crowded to prefer 'simpler' summary in exchange),
> but you'd need to strike a good balance what to discard.  Is the
> fact that the name of branch that got some unspecified new things
> was 'merge8' the most important thing to convey?
> 
> If you make the commit 'title' a short one-line summary, you MUST
> have a blank line after that line.  Otherwise, the 'where does the
> title of this commit object end?' logic will helpfully merge all the
> lines in the first paragraph (i.e. up to the first blank line) into
> one long line, defeating your effort to make the summary simpler by
> losing details.  That is:
> 
>     Merge 6 commits into merge8
> 
>     branch 'branch_with_some_long_name_1'
>     remote-tracking ...
>     ...
> 
> That's it for the 'mechanics', i.e. a discussion about how a good
> design of this 'feature' should look like.
> 
> About the feature itself, I am not sure.  Even though I admit I was
> the one who invented octupus merges, and it does make the history
> look "pretty" in gitk when used judiciously, its practical benefit
> over repeated pairwise merges is doubtful.  Besides, it makes
> bisection less efficient.  So from that point of view, I am not sure
> if we want a feature to encourage creation of more octopus merges.
> 
> I haven't read the code yet---I usually don't before figuring out if
> the feature and its design makes sense---so I have no comment on the
> actual change at this moment.  I may send a separate review message
> later.
> 
> Thanks.
> 

Thank you for feedback.

I totally forgot about title in commit message and short log. I think
I'd like to take your suggestion and modify it a bit.
I want to add some text before enumeration of commits into message like
this:

Merge 6 commits into merge8

Following commits are merged:
branch 'branch_with_some_long_name_1'
remote-tracking ...
...

As for octopus merge, there are still some situations where it has some
advantages over series of pairwise merges, although I agree that it
might be uncommon cases. I can name linking multiple previously
unrelated histories as one such case. Bisect could be useless and
history would look better in my opinion.

If this feature would be fine with updated commit message, I'll update
my changes and send updated patch series.

[RFC PATCH v2 0/2] git-merge: update default commit message

[i.Dark_Templar]

This series of patches updates default commit message for git-merge command.

First patch adds alternative commit message formatting where
each merged object is printed on new line
and adds configuration option to enable new message formatting
when specified number of merged commits is detected.

This feature is turned off by default in first patch.
Second patch is optional and enables new behaviour
when at least two additional commits are merged.

i.Dark_Templar (2):
  git-merge: add option to format default message using multiple lines
  Enable multiline merge commit message by default

 Documentation/config/fmt-merge-msg.txt |   9 ++
 builtin/fmt-merge-msg.c                | 115 ++++++++++++++++++++++++-
 2 files changed, 122 insertions(+), 2 deletions(-)

--
2.24.1

[RFC PATCH v2 1/2] git-merge: add option to format default message using multiple lines

[i.Dark_Templar]

If a lot of objects is merged at once, default commit message
could become one very long line, which might be inconvenient to read.
This change implements an option to change default autogenerated message
so it'd take multiple lines, but each line wouldn't be long.

An artificial example.

Original merge commit message:
    Merge branch 'branch_with_some_long_name_1', remote-tracking branch 'clone/remote_branch_with_some_name', tags 'some_tag' and 'some_other_tag'; commit 'ae46a39cead2b42282abce725e90b561c06e94ba'; commit '33d0281e0eeb2a5e9907ebedc230e28c46865092' into merge7

Multiline merge commit message:
    Merge 6 commits into merge8

    Following commits are merged:
    branch 'branch_with_some_long_name_1'
    remote-tracking branch 'clone/remote_branch_with_some_name'
    tag 'some_tag'
    tag 'some_other_tag'
    commit 'ae46a39cead2b42282abce725e90b561c06e94ba'
    commit '33d0281e0eeb2a5e9907ebedc230e28c46865092'

Signed-off-by: i.Dark_Templar <darktemplar@dark-templar-archives.net>
---
 Documentation/config/fmt-merge-msg.txt |   9 ++
 builtin/fmt-merge-msg.c                | 115 ++++++++++++++++++++++++-
 2 files changed, 122 insertions(+), 2 deletions(-)

diff --git a/Documentation/config/fmt-merge-msg.txt b/Documentation/config/fmt-merge-msg.txt
index c73cfa90b7..7aecf95b68 100644
--- a/Documentation/config/fmt-merge-msg.txt
+++ b/Documentation/config/fmt-merge-msg.txt
@@ -8,3 +8,12 @@ merge.log::
 	most the specified number of one-line descriptions from the
 	actual commits that are being merged.  Defaults to false, and
 	true is a synonym for 20.
+
+merge.usemultiline::
+	Switch merge commit message format to multiline format
+	if merged commits count is greater than or equal to specified
+	value. If specified value is zero or a negative one, this feature
+	is disabled.
+	When multiline commit message format is used, every merged commit
+	will be written using new line. This should ensure that commit message
+	wouldn't become one very long line when there are a lot of merged commits.
diff --git a/builtin/fmt-merge-msg.c b/builtin/fmt-merge-msg.c
index 736f666f64..191824c962 100644
--- a/builtin/fmt-merge-msg.c
+++ b/builtin/fmt-merge-msg.c
@@ -20,6 +20,7 @@ static const char * const fmt_merge_msg_usage[] = {
 };
 
 static int use_branch_desc;
+static int use_multiline = -1;
 
 int fmt_merge_msg_config(const char *key, const char *value, void *cb)
 {
@@ -32,6 +33,8 @@ int fmt_merge_msg_config(const char *key, const char *value, void *cb)
 			merge_log_config = DEFAULT_MERGE_LOG_LEN;
 	} else if (!strcmp(key, "merge.branchdesc")) {
 		use_branch_desc = git_config_bool(key, value);
+	} else if (!strcmp(key, "merge.usemultiline")) {
+		use_multiline = git_config_int(key, value);
 	} else {
 		return git_default_config(key, value, cb);
 	}
@@ -413,6 +416,39 @@ static void shortlog(const char *name,
 	string_list_clear(&subjects, 0);
 }
 
+static int fmt_merge_refs_count(void)
+{
+	int i = 0;
+	int j = 0;
+	int objects_count = 0;
+
+	for (i = 0; i < srcs.nr; i++) {
+		struct src_data *src_data = srcs.items[i].util;
+
+		if (src_data->head_status == 1) {
+			++objects_count;
+			continue;
+		}
+		if (src_data->head_status == 3) {
+			++objects_count;
+		}
+		for (j = 0; j < src_data->branch.nr; j++) {
+			++objects_count;
+		}
+		for (j = 0; j < src_data->r_branch.nr; j++) {
+			++objects_count;
+		}
+		for (j = 0; j < src_data->tag.nr; j++) {
+			++objects_count;
+		}
+		for (j = 0; j < src_data->generic.nr; j++) {
+			++objects_count;
+		}
+	}
+
+	return objects_count;
+}
+
 static void fmt_merge_msg_title(struct strbuf *out,
 				const char *current_branch)
 {
@@ -467,6 +503,68 @@ static void fmt_merge_msg_title(struct strbuf *out,
 		strbuf_addf(out, " into %s\n", current_branch);
 }
 
+static void fmt_merge_msg_title_multiline(struct strbuf *out,
+				const char *current_branch, int count)
+{
+	int i = 0;
+	int j = 0;
+
+	if (!strcmp("master", current_branch))
+		strbuf_addf(out, "Merge %d %s\n", count, (count == 1) ? "commit" : "commits");
+	else
+		strbuf_addf(out, "Merge %d %s into %s\n", count, (count == 1) ? "commit" : "commits", current_branch);
+
+	strbuf_addch(out, '\n');
+
+	if (count == 1)
+		strbuf_addstr(out, "Following commit is merged:\n");
+	else
+		strbuf_addstr(out, "Following commits are merged:\n");
+
+	for (i = 0; i < srcs.nr; i++) {
+		struct src_data *src_data = srcs.items[i].util;
+		int add_origin = 0;
+
+		if (src_data->head_status == 1) {
+			strbuf_addf(out, "%s\n", srcs.items[i].string);
+			continue;
+		}
+
+		add_origin = strcmp(".", srcs.items[i].string);
+
+		if (src_data->head_status == 3) {
+			if (!add_origin)
+				strbuf_addstr(out, "HEAD\n");
+			else
+				strbuf_addf(out, "HEAD of %s\n", srcs.items[i].string);
+		}
+		for (j = 0; j < src_data->branch.nr; j++) {
+			if (!add_origin)
+				strbuf_addf(out, "branch %s\n", src_data->branch.items[j].string);
+			else
+				strbuf_addf(out, "branch %s of %s\n", src_data->branch.items[j].string, srcs.items[i].string);
+		}
+		for (j = 0; j < src_data->r_branch.nr; j++) {
+			if (!add_origin)
+				strbuf_addf(out, "remote-tracking branch %s\n", src_data->r_branch.items[j].string);
+			else
+				strbuf_addf(out, "remote-tracking branch %s of %s\n", src_data->r_branch.items[j].string, srcs.items[i].string);
+		}
+		for (j = 0; j < src_data->tag.nr; j++) {
+			if (!add_origin)
+				strbuf_addf(out, "tag %s\n", src_data->tag.items[j].string);
+			else
+				strbuf_addf(out, "tag %s of %s\n", src_data->tag.items[j].string, srcs.items[i].string);
+		}
+		for (j = 0; j < src_data->generic.nr; j++) {
+			if (!add_origin)
+				strbuf_addf(out, "commit %s\n", src_data->generic.items[j].string);
+			else
+				strbuf_addf(out, "commit %s of %s\n", src_data->generic.items[j].string, srcs.items[i].string);
+		}
+	}
+}
+
 static void fmt_tag_signature(struct strbuf *tagbuf,
 			      struct strbuf *sig,
 			      const char *buf,
@@ -631,8 +729,21 @@ int fmt_merge_msg(struct strbuf *in, struct strbuf *out,
 			die("error in line %d: %.*s", i, len, p);
 	}
 
-	if (opts->add_title && srcs.nr)
-		fmt_merge_msg_title(out, current_branch);
+	if (opts->add_title && srcs.nr) {
+		if (use_multiline <= 0) {
+			fmt_merge_msg_title(out, current_branch);
+		} else {
+			int count;
+
+			count = fmt_merge_refs_count();
+
+			if (count >= use_multiline) {
+				fmt_merge_msg_title_multiline(out, current_branch, count);
+			} else {
+				fmt_merge_msg_title(out, current_branch);
+			}
+		}
+	}
 
 	if (origins.nr)
 		fmt_merge_msg_sigs(out);
-- 
2.24.1

[RFC PATCH v2 2/2] Enable multiline merge commit message by default

[i.Dark_Templar]

Signed-off-by: i.Dark_Templar <darktemplar@dark-templar-archives.net>
---
 builtin/fmt-merge-msg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/builtin/fmt-merge-msg.c b/builtin/fmt-merge-msg.c
index 191824c962..ab445110b0 100644
--- a/builtin/fmt-merge-msg.c
+++ b/builtin/fmt-merge-msg.c
@@ -20,7 +20,7 @@ static const char * const fmt_merge_msg_usage[] = {
 };
 
 static int use_branch_desc;
-static int use_multiline = -1;
+static int use_multiline = 2;
 
 int fmt_merge_msg_config(const char *key, const char *value, void *cb)
 {
-- 
2.24.1

Re: [RFC PATCH v2 1/2] git-merge: add option to format default message using multiple lines

[Junio C Hamano]

"i.Dark_Templar" <darktemplar@dark-templar-archives.net> writes:

> +static int use_multiline = -1;
>  
>  int fmt_merge_msg_config(const char *key, const char *value, void *cb)
>  {
> @@ -32,6 +33,8 @@ int fmt_merge_msg_config(const char *key, const char *value, void *cb)
>  			merge_log_config = DEFAULT_MERGE_LOG_LEN;
>  	} else if (!strcmp(key, "merge.branchdesc")) {
>  		use_branch_desc = git_config_bool(key, value);
> +	} else if (!strcmp(key, "merge.usemultiline")) {
> +		use_multiline = git_config_int(key, value);
>  	} else {
>  		return git_default_config(key, value, cb);
>  	}
> @@ -413,6 +416,39 @@ static void shortlog(const char *name,
>  	string_list_clear(&subjects, 0);
>  }
>  
> +static int fmt_merge_refs_count(void)
> +{
> +	int i = 0;
> +	int j = 0;
> +	int objects_count = 0;

Call it "object_count" and drop "j"; that's shorter.

Also, this is a "STATIC" function, an implementation detail of the
fmt_merge_msg program.  There is no need to repeat that fact by
replicating fmt_merge_ in its name to differenciate with other
things, unlike the functions that are visible from other places.

Just call it "count_srcs()" or something like that and do not use
the word "ref" in its name, as "merging refs" is probably too
ancient, limiting and misleading concept---we do not merge "refs".
We merge commits (and more recently) tags, and "refs" is merely one
of the ways to name these things that are merged.


> +	for (i = 0; i < srcs.nr; i++) {
> +		struct src_data *src_data = srcs.items[i].util;
> +
> +		if (src_data->head_status == 1) {
> +			++objects_count;
> +			continue;
> +		}
> +		if (src_data->head_status == 3) {
> +			++objects_count;
> +		}

This part deserves commenting.  The bit #0 of head_status is special
in that it signals a pull of the default branch (HEAD) of the remote
repository, and it is special because in that case (and only in that
case) none of the string lists in src_data is updated, so the number
of merged heads is one more than the case where the bit #0 is off.

> +		for (j = 0; j < src_data->branch.nr; j++) {
> +			++objects_count;
> +		}
> +		for (j = 0; j < src_data->r_branch.nr; j++) {
> +			++objects_count;
> +		}
> +		for (j = 0; j < src_data->tag.nr; j++) {
> +			++objects_count;
> +		}
> +		for (j = 0; j < src_data->generic.nr; j++) {
> +			++objects_count;
> +		}

Isn't it sufficient to add .nr to object_count?  Why increment
object_count by one as many times as j counts up from 0 to .nr?

If the merge involves only the remote HEAD, then the lists are all
empty, isn't it?  I do not see the point of treating the case where
head_status is 3 == 1|2 any special, so the following is sufficient
as the replacement for the above and should be far easier to follow,
no?  Or am I missing something subtle in your version?

		if (src_data->head_status & 01)
			/* 
                         * the set of merged heads includes the
                         * default branch of the remote, aka HEAD,
			 * which is not counted in any of the lists
			 * in src_data.
			 */
			object_count++;

                object_count += (src->data->branch.nr +
                                 src->data->r_branch.nr +
                                 src->data->tag.nr +
                                 src->data->generic.nr);

By the way, if you read the original code, you may have noticed that
our codebase prefers post-increment over pre-increment, when the
difference does not matter (in other words, "a = ++b;" is perfectly
legit; it is just that we do not say "++b;" when "b++;" would do).

> +	}
> +
> +	return objects_count;
> +}
> +
>  static void fmt_merge_msg_title(struct strbuf *out,
>  				const char *current_branch)
>  {
> @@ -467,6 +503,68 @@ static void fmt_merge_msg_title(struct strbuf *out,
>  		strbuf_addf(out, " into %s\n", current_branch);
>  }
>  
> +static void fmt_merge_msg_title_multiline(struct strbuf *out,
> +				const char *current_branch, int count)
> +{
> +	int i = 0;
> +	int j = 0;
> +
> +	if (!strcmp("master", current_branch))
> +		strbuf_addf(out, "Merge %d %s\n", count, (count == 1) ? "commit" : "commits");
> +	else
> +		strbuf_addf(out, "Merge %d %s into %s\n", count, (count == 1) ? "commit" : "commits", current_branch);

Overlong lines.

> +	strbuf_addch(out, '\n');
> +
> +	if (count == 1)
> +		strbuf_addstr(out, "Following commit is merged:\n");
> +	else
> +		strbuf_addstr(out, "Following commits are merged:\n");

The above makes me wonder if you are better off having "if there is
only one, do these things, otherwise do these other things" at the
top level, i.e.

	if (count == 1) {
		strbuf_addstr(out, "Merge 1 commit");
		if (strcmp(current_branch, "master"))
			strbuf_addstr(out, " into %s", current_branch);
		strbuf_addstr(out, "\n\nFollowing commit is ...");
	} else {
		...similarly...
	}

But stepping back a bit, is there a point in handing count==1 case
in this new format in the first place?  Why waste the most precious
information real estate, which is the title line, to say a lot less
informative "merge 1 commit" instead of what topic is merged there?

Also, I am not sure if "Following commits are merged" is a good
message for a few reasons.

 - Obviously, we allow pulling and merging a signed tag and in that
   case, we are merging a tag, not a commit.

 - When we pull a topic branch and nothing else, the above code
   would say "Merge 1 commit", but there may probably be more than
   one commit on the history leading to that commit we are merging
   into our history.


What actually is happening, instead of "merge 1 commit", is that we
are merging one lineage of history, which may have one or more
commits.  The phrase suitable to call the lineage of history may be
"a topic branch", but it may be "a release tag", in which case what
you are merging would be the entire history built while developing
towards that tag that you have been missing.

Re: [RFC PATCH v2 1/2] git-merge: add option to format default message using multiple lines

[i.Dark_Templar]

Hi

Thank you for your feedback!

09.03.2020 19:20, Junio C Hamano пишет:
> "i.Dark_Templar" <darktemplar@dark-templar-archives.net> writes:
> 
>> +static int use_multiline = -1;
>>  
>>  int fmt_merge_msg_config(const char *key, const char *value, void *cb)
>>  {
>> @@ -32,6 +33,8 @@ int fmt_merge_msg_config(const char *key, const char *value, void *cb)
>>  			merge_log_config = DEFAULT_MERGE_LOG_LEN;
>>  	} else if (!strcmp(key, "merge.branchdesc")) {
>>  		use_branch_desc = git_config_bool(key, value);
>> +	} else if (!strcmp(key, "merge.usemultiline")) {

I'm wondering if this config option name could be improved, but out of
ideas at the moment. Maybe you have some ideas?

>> +		use_multiline = git_config_int(key, value);
>>  	} else {
>>  		return git_default_config(key, value, cb);
>>  	}
>> @@ -413,6 +416,39 @@ static void shortlog(const char *name,
>>  	string_list_clear(&subjects, 0);
>>  }
>>  
>> +static int fmt_merge_refs_count(void)
>> +{
>> +	int i = 0;
>> +	int j = 0;
>> +	int objects_count = 0;
> 
> Call it "object_count" and drop "j"; that's shorter.
> 
> Also, this is a "STATIC" function, an implementation detail of the
> fmt_merge_msg program.  There is no need to repeat that fact by
> replicating fmt_merge_ in its name to differenciate with other
> things, unlike the functions that are visible from other places.
> 
> Just call it "count_srcs()" or something like that and do not use
> the word "ref" in its name, as "merging refs" is probably too
> ancient, limiting and misleading concept---we do not merge "refs".
> We merge commits (and more recently) tags, and "refs" is merely one
> of the ways to name these things that are merged.
> 
> 

Thanks, I'll rename this function to 'count_srcs'.

>> +	for (i = 0; i < srcs.nr; i++) {
>> +		struct src_data *src_data = srcs.items[i].util;
>> +
>> +		if (src_data->head_status == 1) {
>> +			++objects_count;
>> +			continue;
>> +		}
>> +		if (src_data->head_status == 3) {
>> +			++objects_count;
>> +		}
> 
> This part deserves commenting.  The bit #0 of head_status is special
> in that it signals a pull of the default branch (HEAD) of the remote
> repository, and it is special because in that case (and only in that
> case) none of the string lists in src_data is updated, so the number
> of merged heads is one more than the case where the bit #0 is off.
> 

I didn't know about such details. Thanks.

>> +		for (j = 0; j < src_data->branch.nr; j++) {
>> +			++objects_count;
>> +		}
>> +		for (j = 0; j < src_data->r_branch.nr; j++) {
>> +			++objects_count;
>> +		}
>> +		for (j = 0; j < src_data->tag.nr; j++) {
>> +			++objects_count;
>> +		}
>> +		for (j = 0; j < src_data->generic.nr; j++) {
>> +			++objects_count;
>> +		}
> 
> Isn't it sufficient to add .nr to object_count?  Why increment
> object_count by one as many times as j counts up from 0 to .nr?
> 

That's my fault, I overlooked optimization here.

> If the merge involves only the remote HEAD, then the lists are all
> empty, isn't it?  I do not see the point of treating the case where
> head_status is 3 == 1|2 any special, so the following is sufficient
> as the replacement for the above and should be far easier to follow,
> no?  Or am I missing something subtle in your version?
> 
> 		if (src_data->head_status & 01)
> 			/* 
>                          * the set of merged heads includes the
>                          * default branch of the remote, aka HEAD,
> 			 * which is not counted in any of the lists
> 			 * in src_data.
> 			 */
> 			object_count++;
> 
>                 object_count += (src->data->branch.nr +
>                                  src->data->r_branch.nr +
>                                  src->data->tag.nr +
>                                  src->data->generic.nr);
> 
> By the way, if you read the original code, you may have noticed that
> our codebase prefers post-increment over pre-increment, when the
> difference does not matter (in other words, "a = ++b;" is perfectly
> legit; it is just that we do not say "++b;" when "b++;" would do).
> 

I copied behaviour of 'fmt_merge_msg_title' function here. Thanks for
clarifying special cases and optimizing it. I didn't know most of these
details about head_status and branches/tags/etc lists. I'll replace it
with your optimized version.

>> +	}
>> +
>> +	return objects_count;
>> +}
>> +
>>  static void fmt_merge_msg_title(struct strbuf *out,
>>  				const char *current_branch)
>>  {
>> @@ -467,6 +503,68 @@ static void fmt_merge_msg_title(struct strbuf *out,
>>  		strbuf_addf(out, " into %s\n", current_branch);
>>  }
>>  
>> +static void fmt_merge_msg_title_multiline(struct strbuf *out,
>> +				const char *current_branch, int count)
>> +{
>> +	int i = 0;
>> +	int j = 0;
>> +
>> +	if (!strcmp("master", current_branch))
>> +		strbuf_addf(out, "Merge %d %s\n", count, (count == 1) ? "commit" : "commits");
>> +	else
>> +		strbuf_addf(out, "Merge %d %s into %s\n", count, (count == 1) ? "commit" : "commits", current_branch);
> 
> Overlong lines.
> 

Thanks, I'll fix it.

>> +	strbuf_addch(out, '\n');
>> +
>> +	if (count == 1)
>> +		strbuf_addstr(out, "Following commit is merged:\n");
>> +	else
>> +		strbuf_addstr(out, "Following commits are merged:\n");
> 
> The above makes me wonder if you are better off having "if there is
> only one, do these things, otherwise do these other things" at the
> top level, i.e.
> 
> 	if (count == 1) {
> 		strbuf_addstr(out, "Merge 1 commit");
> 		if (strcmp(current_branch, "master"))
> 			strbuf_addstr(out, " into %s", current_branch);
> 		strbuf_addstr(out, "\n\nFollowing commit is ...");
> 	} else {
> 		...similarly...
> 	}
> 
> But stepping back a bit, is there a point in handing count==1 case
> in this new format in the first place?  Why waste the most precious
> information real estate, which is the title line, to say a lot less
> informative "merge 1 commit" instead of what topic is merged there?
> 

By default, this new format is disabled. In patch 2 it's enabled only
when at least 2 new objects are merged. Due to that new message format
shouldn't ever be used with default settings for only 1 merged object,
but user could set new configuration option to '1' and hit this code path.

If such format for just 1 merged object is undesired, I can modify code
and documentation to make sure it turns on only when at least 2 objects
are merged, and get rid of 1 merged object use-case after that.

> Also, I am not sure if "Following commits are merged" is a good
> message for a few reasons.
> 
>  - Obviously, we allow pulling and merging a signed tag and in that
>    case, we are merging a tag, not a commit.
> 
>  - When we pull a topic branch and nothing else, the above code
>    would say "Merge 1 commit", but there may probably be more than
>    one commit on the history leading to that commit we are merging
>    into our history.
> 
> 
> What actually is happening, instead of "merge 1 commit", is that we
> are merging one lineage of history, which may have one or more
> commits.  The phrase suitable to call the lineage of history may be
> "a topic branch", but it may be "a release tag", in which case what
> you are merging would be the entire history built while developing
> towards that tag that you have been missing.
> 

I'll describe a bit why I used a word 'commit' in this code. When
deciding how to name merged objects, I came down to two options: just
'object' or 'commit'. I used 'commit' because 'man git-merge' usually
uses this word. What word would you want to use here instead? An
'object'? 'History'? Something else?