On Fri, Dec 27, 2019 at 11:21:41AM +0000, Richard Earnshaw (lists) wrote: > On 26/12/2019 18:59, Joseph Myers wrote: > > On Thu, 26 Dec 2019, Jakub Jelinek wrote: > >> 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.
Archaeology is much simpler still if people do not do merges at all, but use a rebase (or rebase-like, e.g. quilt) workflow. That way, there are no bad changes that have to be undone later, etc. Ideally everything comes in as small, well thought out patches. Segher
