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

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