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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 9, 2020, 17:44 UTC
Message-ID: <xmqqtv3z1wq4.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20200209131623.5827-2-darktemplar@dark-templar-archives.net>

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

Show 18 quoted lines

> 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.