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
