Re: fast forward merge overwriting my code

From: Philip Oakley <philipoakley@iee.email>
Date: May 27, 2021, 15:12 UTC
Message-ID: <90579aaf-2fa6-4641-29e2-43711ccafb86@iee.email>
In-Reply-To: <60afa5e07bcd9_2056d2084d@natae.notmuch>

On 27/05/2021 15:00, Felipe Contreras wrote:

Show 11 quoted lines

> Philip Oakley wrote:
>> On 27/05/2021 00:34, Felipe Contreras wrote:
>>> Yes, but that is a separate issue.
>>>
>>> Right now they are able to resolve conflicts with a jupyter mergetool.
>> I don't believe that ("resolve") is true in the sense they would like. I
>> don't think they are really 'merging' in an all-in-one `git merge`
>> sense, rather they are [trying to] splitting and patching and commenting
>> the changes.
> He explicitly mentioned a merge, but ultimately it doesn't matter, the
> mergetool can be used in other scenarios, like `git am`.

True, though I see the server side aspects as also an important part of the process pain.

Show 7 quoted lines

>
> I did try to setup those tools, nbdime does setup a merge tool [1].
>
> Cheers.
>
> [1] https://nbdime.readthedocs.io/en/latest/
>

Thanks for that reference. I did like that the picture of the 'problem' example was the same as the nbdime diff's solution ;-) [1]

The article does give a good start for thinking about the wider diffing & merging problems for tools with more complex conceptual 'abstract syntax trees' and file representations.

Philip [1] https://nbdime.readthedocs.io/en/latest/_images/nbdiff-web.png