Re: [PATCH v3 0/5] built-in add -p: support diff-so-fancy better

"Johannes Schindelin via GitGitGadget" [off-list ref]
writes:

 * That logic was now corrected to see whether that space is really needed.
 * To verify that the logic does what we need it to do, the added regression
   test now specifically tests for that (single) extra space that we want to
   be inserted.

 * Rebased to the current tip of the main branch to avoid a merge conflict
   with 716c1f649e3 (pipe_command(): mark stdin descriptor as non-blocking,
   2022-08-17).

I'd prefer you (or any other contributor) not to pick a more recent
base only to work around a merge conflict, especially when it is
something simple (like this case, where both sides added a new test
piece each in a way that semantically do not conflict).  I'll ask
the author to rebase if the conflicts becomes unmanageable.

We promoted the built-in one as the primary implementation in
2.37.0; I think we want to keep this fix mergeable down to the
2.37.x maintenance track (either by me, or by distro LTS folks who
are motivated enough).

This time, as you can guess by my above description on the exact way
how conflict happens, I've rebased the series back for 2.37.x and
will resolve the conflict myself (and make sure the result matches
the application of these patches directly on top of 'master').

It appears that this round is good to go down to 'next' soonish, but
let's see what others find.

Thanks.

Hi Junio,

On Mon, 29 Aug 2022, Junio C Hamano wrote:

"Johannes Schindelin via GitGitGadget" [off-list ref]
writes:

quoted

 * That logic was now corrected to see whether that space is really needed.
 * To verify that the logic does what we need it to do, the added regression
   test now specifically tests for that (single) extra space that we want to
   be inserted.

quoted

 * Rebased to the current tip of the main branch to avoid a merge conflict
   with 716c1f649e3 (pipe_command(): mark stdin descriptor as non-blocking,
   2022-08-17).

I'd prefer you (or any other contributor) not to pick a more recent
base only to work around a merge conflict, [...]

Noted. I just wanted to be nice.

We promoted the built-in one as the primary implementation in
2.37.0; I think we want to keep this fix mergeable down to the
2.37.x maintenance track (either by me, or by distro LTS folks who
are motivated enough).

This time, as you can guess by my above description on the exact way
how conflict happens, I've rebased the series back for 2.37.x and
will resolve the conflict myself (and make sure the result matches
the application of these patches directly on top of 'master').

It appears that this round is good to go down to 'next' soonish, but
let's see what others find.

Sounds good.

Thanks,
Dscho