09.02.2020 20:44, Junio C Hamano пишет: > "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. > 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.
