On Thu, 19 Dec 2019, Bernd Schmidt wrote:

> On 12/18/19 10:55 PM, Joseph Myers wrote:
> > git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-3a.git
> 
> I cloned this one and started trying random things again.
> The previous one had some strange-looking merge commits, but it sounded like
> that was a known issue, and indeed the ones I had seen were fixed in this new
> version.
> I decided to write a small script to check whether there were any merge
> commits with more than two parents, and there are a few which have three. One
> commit seems to occur as a parent in all of these:
> 422854db0e8605867e0834035aa2b1da1b71cbfb. An example is
> b743e467e43e6211f2c2537f1f07bbceb4d3aa61, apparently from spu-4_5-branch.
> 
> No idea whether there is an issue or whether this is worth looking at, but I
> figured I'd point it out at least.

b743e467e43e6211f2c2537f1f07bbceb4d3aa61 is r152464, from 
named-addr-spaces-branch.

This merge is the first one that added an svn:mergeinfo property on 
named-addr-spaces-branch, which previously had only svnmerge-integrated 
(the svn:mergeinfo property was copied from the one that was on trunk at 
that time).  That svn:mergeinfo property specifies merges from 
/branches/cxx0x-lambdas-branch, /branches/lto and /trunk, and the merge 
parents are for the first two of those.  For /trunk, it only specifies two 
revisions, which is clearly not a valid merge and this version of 
reposurgeon avoids creating merge commits for cherry-picks.  
svnmerge-integrated specifies /trunk:1-151687,151691-152437, which would 
be a valid merge from trunk (there are no trunk revisions in the gap) but 
reposurgeon only looks at svnmerge-integrated if svn:mergeinfo is empty.  
I'll file a request that it take the union of revision ranges from the two 
properties, which ought to be easy to implement.  Once it recognises that 
commit as a merge from trunk, it will should automatically discard the 
other merge parents because it now avoids adding a merge parent that is an 
ancestor of another merge parent.

I.e. this is an artifact of someone having done a merge with svnmerge.py 
that brought in svn:mergeinfo from another branch where SVN's native merge 
tracking had been used, and should be straightforward to fix.

-- 
Joseph S. Myers
jos...@codesourcery.com

Reply via email to