en/remerge-diff-fixes (Was: Re: What's cooking in git.git (Sep 2022, #01; Mon, 5))

From: Elijah Newren <newren@gmail.com>
Date: Sep 6, 2022, 14:17 UTC
Message-ID: <CABPp-BEX0ScdAvQ1YaPUPNQ197mhcRMEFnHBoJ_0MBTK3nv_DA@mail.gmail.com>
In-Reply-To: <xmqqilm1yp3m.fsf@gitster.g>

Hi Junio,

On Tue, Sep 6, 2022 at 12:41 AM Junio C Hamano <gitster@pobox.com> wrote:

Show 9 quoted lines

> * en/remerge-diff-fixes (2022-09-02) 3 commits
>  - diff: fix filtering of merge commits under --remerge-diff
>  - diff: fix filtering of additional headers under --remerge-diff
>  - diff: have submodule_format logic avoid additional diff headers
>
>  Fix a few "git log --remerge-diff" bugs.
>
>  Will probably need to rebase to make it mergeable to 'maint'.
>  source: <pull.1342.v3.git.1662090810.gitgitgadget@gmail.com>

It rebases to 'maint' without conflict and the result correctly applies there...but rebasing to maint causes it to drop a line of code ("TEST_PASSES_SANITIZE_LEAK=true") which is called out in the commit message, making the commit message look funny. Also, while that line removal turns out to not matter to maint (because the leak checker was already off), it is critical for main. So, if you merge the rebased result back to main, the leak check will fail -- unless the merge back is an "evil merge" that restores the removal of that line.

So, which of the following would you prefer?
  * A separate series for maint and main?
  * Just ignore maint?
  * Me to rebase on maint to tweak the commit message, and then you
carefully reinstate the line removal as part of the merge back to
main?