Commit messages and the move to git

[Joseph Myers]

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
joseph@codesourcery.com