Re: fast forward merge overwriting my code

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Philip Oakley wrote:
> On 26/05/2021 19:33, Felipe Contreras wrote:
> > Philip Oakley wrote:
> >> On 26/05/2021 03:53, Felipe Contreras wrote:
> >>> Andre Ulrich wrote:
> >>>> So the last point is where we still want to do some fine tuning. Right  
> >>>> now this looks about: my prof fetches my edits and locally checks out  
> >>>> a branch to compare the changes with git diff.
> >>>> But in this diff view you can't edit the files. So you have to  
> >>>> separately open up another window to edit the changes (lets say my  
> >>>> prof only wants to keep some of my changes, but not all).
> >>> So for example after fetching your changes your professor sees this:
> >> Part of Andre's problem was that this diff wasn't stable because the
> >> underlying file format is said to be json so items can move around
> >> without issue (e.g. key value pairs swapping position) and that they
> >> aren't really working on the json file (it may as well be binary..) but
> >> on the jupytper notebook display view, so one step removed from the 'diff'.
> > Andre said they use the diff view, and he wants to be able to edit it.
> > Not sure how else would you interpret "But in this diff view you can't
> > edit the files".
> >
> In
> https://lore.kernel.org/git/20210524061355.Horde.I7EpK9A1l-KtI_TwFo97eNd@xxxxxxxxxxxxxxxxxxx/
> Abdre did say they used the special jupyter notebook diff viewer.

Yes, but that is a separate issue.

Right now they are able to resolve conflicts with a jupyter mergetool.
The tool gets rid of all the extra noise so the user is able to focus
only on the actual important changes. When they exit the tool, their
changes are properly staged.

The problem Andre described in [1] appears when mergetool does *not*
run. In that case the user is forced to run `git diff` (jupyter difftool
will be used), edit the file manually with some viewer, `git add
--update`, and then run `git diff --cached` to verify the changes.

In case an unwanted change sneaks by, the user would have to edit the
file again, or do `git checkout --patch` to selectively remove chunks
(and since this tools presents the diffs in reverse, it's
counterintuitive and error-prone).

This is far from ideal.


The problem is that there is no `git stage edit`, in order to launch the
mergetool.

I just wrote an example `git stage-edit` [2] that does launch the
mergetool even if there are no merge conflicts, allowing the user to
modify the stage directly and with no hassle.

Cheers.

[1] https://lore.kernel.org/git/20210522154815.Horde.rqiNSyIc3CGJECACotWLO1T@xxxxxxxxxxxxxxxxxxx/
[2] https://dpaste.com/62XS8TTXP

-- 
Felipe Contreras



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux