From: Philip Oakley <philipoakley@iee.email>
Date: Thu, 27 May 2021 15:12:41 GMT
Subject: Re: fast forward merge overwriting my code
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:
> 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.
>
> 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