On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote: > Well a lot of that is a property of the conversion tool. git svn does a > relatively poor job of anything other than straight history (I believe it just > ignores the non-linear information. I don't believe any tool can recreate > information for cherry-picking unless it's recorded in the SVN meta-data. > Eric would be better placed to comment here.
I think the main thing to make sure of in the conversion regarding that issue is that cherry-picks do *not* turn into merge commits (so that e.g. "git tag --contains" can be reasonably accurate about which releases contain a given commit on master; the other piece of making "git tag --contains" more accurate is my list of branch and tag reparentings from the cvs2svn era). That is: * If the history on a branch includes a commit that copied a particular file (say, a testcase) from trunk, the fact of the copy (of some file or subdirectory rather than actually creating / replacing the branch itself) should *not* by itself, in the absence of merge property changes, suffice to create a history relation, because in GCC that's typically a cherry-pick (backports of a bug fix, including creating new testcases, are sometimes done in a way that creates such copy relations, for example, but it would be wrong for it put the corresponding trunk commit in the ancestry of the branch commit). * Similarly, if the SVN merge tracking information shows that a commit was a cherry-pick of a single revision - because SVN does track that single revisions were merged somewhere. (reposurgeon definitely has logic for that, see the comment "Ignore single-rev fields, they are cherry-picks.".) -- Joseph S. Myers jos...@codesourcery.com
