On Mon, 20 May 2019, Richard Biener wrote: > There's not many details there but I always thought that the > "interesting" parts of the GCC history (official branches and trunk) > do _not_ contain merge commits so the GCC history forms a tree > rather than a DAG. (I'm not sure if there's an easy way to verify > whether there are any merge commits on a specific branch)
There are plenty of merge commits on development branches, which are of value to keep so that changes made on such a branch are clearly distinguished from those that were merged into it. > There may be merges hidden inside the cvs2svn converted part > as well as in user branches (definitely merges from trunk to branch). cvs2svn history won't have merge commits in any form that can be handled automatically (simply because CVS doesn't have any form of merge tracking that could be converted to SVN - and SVN's own merge tracking long postdates the repository conversion from CVS). What it *does* have is messed up branchpoints (cvs2svn had a habit of picking the wrong commit to copy to form a branch based on the branchpoints for each individual ,v file in CVS - and then fixing it up with another synthetic commit to restore files to the actual form they had when the branch was created - or something like that, anyway, and similar issues for tags). If you're looking at history around the creation of an old branch or tag, those are confusing in practice. reposurgeon has logic to fix up at least some such messes created by cvs2svn and pick a more sensible branchpoint. (It's possible some branches from that era genuinely don't start with a copy of a single revision from trunk, or whatever branch they were based on - CVS branch creation is not an atomic operation and could end up with inconsistent versions of different files. But cvs2svn was bad in the common case where there is a single revision that was copied, but cvs2svn chose some other revision + fixups anyway.) -- Joseph S. Myers jos...@codesourcery.com
