On 26/12/2019 18:59, Joseph Myers wrote: > On Thu, 26 Dec 2019, Jakub Jelinek wrote: > >> On Thu, Dec 26, 2019 at 04:58:22PM +0000, Joseph Myers wrote: >>> If we don't want merge commits on git master for the cases where people >>> put merge properties on trunk in the past, we can use a reposurgeon >>> "unmerge" command in gcc.lift to stop the few commits in question from >>> being merge commits (while keeping all other merges as-is). (The merges >>> of trunk into other branches that copied merge properties from trunk into >>> those branches will still be handled correctly, with exactly two parents >>> rather than regaining the extra parents corresponding to the merges into >>> trunk that Bernd noted in an earlier version of the conversion, because >>> the processing that avoids redundant merge parents takes place well before >>> any unmerge commands are executed - so at the time of that processing, >>> reposurgeon knows that those other branches are in fact in the ancestry of >>> trunk, even if we remove that information in the final git repository.) >> >> Yes, I'd prefer the trunk to have no merge commits (in svn I've removed the >> svn:mergeinfo property on the trunk when it appeared too). > > I've added the unmerge commands for the three commits in question to > gcc.lift. >
I'm not really sure I understand why we don't want merge commits into trunk, especially for large changes. Performing archaeology on a change is just so much easier if the development history is just there. Without the merge information, if you're tracking down the reason for a bug, you get to the merge, and then have to go find the branch where the development was done and start the process all over again. With merge information, tools like git blame will show which commit during development touched the relevant line last and a major step in analysis is vastly simplified. R.
