On Wed, Jul 18, 2018 at 3:03 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > * en/rebase-i-microfixes (2018-06-27) 3 commits > (merged to 'next' on 2018-07-11 at d913ca0f77) > + git-rebase--merge: modernize "git-$cmd" to "git $cmd" > + Fix use of strategy options with interactive rebases > + t3418: add testcase showing problems with rebase -i and strategy options > > Will merge to 'master'. This series showed up in the "Graduated to master" section of your email and the series shows up on master; did you just forget to remove this last line? > * en/abort-df-conflict-fixes (2018-07-16) 2 commits > - read-cache: fix directory/file conflict handling in read_index_unmerged() > - t1015: demonstrate directory/file conflict recovery failures > > "git merge --abort" etc. did not clean things up properly when > there were conflicted entries in certain order that are involved > in D/F conflicts. This has been corrected. > > This may have to be rebased on an older maintenance track before > moving forward. Would you like me to rebase on maint and resubmit? Alternatively, git cherry-pick -Xours master..en/abort-df-conflict-fixes will backport the fixes to maint, with the only downside that it leaves some unnecessary (but innocuous) double 'git reset --hard' invocations in t6042. Just let me know whatever is easiest for you. > * en/t6042-insane-merge-rename-testcases (2018-07-03) 3 commits > - t6042: add testcase covering long chains of rename conflicts > - t6042: add testcase covering rename/rename(2to1)/delete/delete conflict > - t6042: add testcase covering rename/add/delete conflict type > > Various glitches in the heuristics of merge-recursive strategy have > been documented in new tests. > > Will merge to 'next'. > > I am not sure if there is a single "correct" answer everybody can > agree on for each of these "insane" cases, though. Yeah, I agree. I was a little unsure about adding the expected "correct" answer in these testcases for fear I would just end up modifying it whenever I finally implement a fix. However, it was clear that current handling for these testcases is suboptimal, and ultimately I decided it'd make sense to just take my best guess at "correct" for now and deal with any modifications later. *shrug* I'm not sure what, if any changes to make to this series because of this, though; for now, I think it's fine as-is.
