Re: What's cooking in git.git (Jul 2018, #02; Wed, 18)

From: Elijah Newren <newren@gmail.com>
Date: Jul 19, 2018, 17:10 UTC
Message-ID: <CABPp-BFSh2KYuBAWZcMUZ6NS0VYc4NNGTaTS3jUGiWm+BO4+Wg@mail.gmail.com>
In-Reply-To: <xmqqtvowi4l3.fsf@gitster-ct.c.googlers.com>

On Wed, Jul 18, 2018 at 3:03 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 7 quoted lines

> * 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?

Show 10 quoted lines

> * 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.

Show 12 quoted lines

> * 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.