On Fri, Dec 27, 2019 at 11:35:21AM +0000, Joseph Myers wrote: > On Fri, 27 Dec 2019, Richard Earnshaw (lists) wrote: > > > 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. > > To some extent it fits with the principle of separating changes to > workflow from the actual move to git (as the existing state is that we > have a linear history on trunk and the few merge properties that were > there were later deleted). So after the conversion we could consider if > for future merges we wish to use merge commits.
SVN mergeinfo is not representable in Git. It records which changesets have been copied over from one branch to another. Git doesn't do changesets *at all*: it just stores tree contents, and it records one or multiple parents for every commit. That isn't actually derivable from the SVN info. You can guess, and you can guess wrong. Branch merges do not mesh well with our commit policies, fwiw: everything should normally be posted for public review on the mailing lists. This does not really work for commits that have been set in stone months before. Segher
