"i.Dark_Templar" <darktemplar@xxxxxxxxxxxxxxxxxxxxxxxxx> 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.
