Date: Tue, 16 Jun 2020 14:41:57 -0400 From: Ed Maste <emaste@freebsd.org> To: freebsd-git@freebsd.org Subject: Next odd commit affecting `git subtree split` experiments with contrib/elftoolchain Message-ID: <CAPyFy2DR6R4S7kgkRtrWzPBuD_6QR=A_hU=sP%2BLm==Y61AKhsA@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
I'm currently excluding the following additional revisions from mergeinfo parsing (on gig_conv 9ae420c081): 242545 249429 250837 255263 255477 256424 265006 265006 265044 265547 265720 267888 283595 It may not be necessary to exclude all of these - they're just the list I've arrived at, after iterative trial and error. When I run `git subtree split --prefix=contrib/elftoolchain` this includes some legitimate, unnecessary, but innocuous commits - e.g. r298092 is included, which tracks a long-running project branch that brought in elftoolchain updates in MFH commits, but didn't otherwise touch elftoolchain on the branch. These clutter the history slightly but cause no real issue. I've found one new class of strange commit - r265044, which I've excluded from mergeinfo parsing (in the above list). However, svnweb highlights an issue: https://svnweb.freebsd.org/base?limit_changes=0&view=revision&revision=265044 projects/bmake/contrib/elftoolchain/ (Copied from head/contrib/elftoolchain, r265036) It looks like contrib/elftoolchain was added to svn head during the time that the /projects/bmake/ was in use, and brought to that projects branch via a MFH. It looks like this triggers svn2git's existing svn cp-based merge detection. I think svn2git is doing the right thing here, it just legitimately triggers the existing issue/bug in subtree split.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPyFy2DR6R4S7kgkRtrWzPBuD_6QR=A_hU=sP%2BLm==Y61AKhsA>