git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Philip Oakley <philipoakley@iee.email>
To: Felipe Contreras <felipe.contreras@gmail.com>,
	Andre Ulrich <andre.ulrich@smail.fh-koeln.de>,
	"brian m. carlson" <sandals@crustytoothpaste.net>
Cc: Johannes Sixt <j6t@kdbg.org>, Git Mailing List <git@vger.kernel.org>
Subject: Re: fast forward merge overwriting my code
Date: Thu, 27 May 2021 13:05:12 +0100	[thread overview]
Message-ID: <02bbe080-cd8a-cc7d-5dbc-9231b51c4baf@iee.email> (raw)
In-Reply-To: <60aedb22c075e_4bd420896@natae.notmuch>

On 27/05/2021 00:34, Felipe Contreras wrote:
> 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@webmail.th-koeln.de/
>> 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.

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.

Aside: In my previous employment it just wasn't possible to diff a
tool's save output (MathCAD, a graphic maths whiteboard) because the
structure of their XML file was not conventionally 'linear' -
rearranging object position on the canvas did not move them in the file,
you had to 'guess' (try and visualise) the objects movement and effect
on computational order. It just wasn't worth the effort as the supplier
didn't have useful diff tool. I Feel that Jupyter is better than that,
but still awkward.

> 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. 

Here they are (in my mind) highlighting the GitLab server side merge
process, which only (IIUC) showing the git diff, and not the jupyter
diff, meaning they have to fetch and then work in the jupyter tool, not Git.

> 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.

I'd misremembered the --update option, and it possibly doesn't do what
the user expects if they expect just the staged files (rather than all
the tracked index files) updated to take on-board their tweaks (i.e. mid
review)
>
> 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).
I'd agree that the whole process for such tools (because they break
linear code conventions) is, as you say, "counter-intuitive 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 see it the other way around (I think). I see it as Git getting out of
the way for a period and supporting that other tool's review process,
rather than assuming that the git-way is the-right-way.

> 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@webmail.th-koeln.de/
> [2] https://dpaste.com/62XS8TTXP
>
Hopefully, Andre can put a little information about just how the mid
'merge/review' process actually happens, and the pain points, to avoid
the discussion talking in thin air...

There may be terminology confusion because of the way that *server based
cooperation* goes via _Pull/Merge Requests_, when really they are
*Review Requests*, and no one (in that situation) actually expects them
to be accepted as-is anyway, rather they are 'returned with comments for
rework' or 'reworked before merge'.

Philip

  reply	other threads:[~2021-05-27 12:05 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-22 15:48 fast forward merge overwriting my code Andre Ulrich
2021-05-22 17:12 ` Philip Oakley
2021-05-23 15:01   ` Junio C Hamano
2021-05-24  9:50     ` Philip Oakley
2021-05-23  9:48 ` Johannes Sixt
2021-05-23 23:58   ` brian m. carlson
2021-05-24  6:13     ` Andre Ulrich
2021-05-24 11:13       ` Bagas Sanjaya
2021-05-24 13:16       ` Philip Oakley
2021-05-24 15:06         ` Andre Ulrich
2021-05-24 18:48           ` Philip Oakley
2021-05-25 15:14             ` Philip Oakley
2021-05-30  5:31             ` David Aguilar
2021-05-30 11:00               ` Philip Oakley
2021-05-24 17:47       ` Igor Djordjevic
2021-05-26  2:53       ` Felipe Contreras
2021-05-26 11:06         ` Philip Oakley
2021-05-26 18:33           ` Felipe Contreras
2021-05-26 20:35             ` Philip Oakley
2021-05-26 23:34               ` Felipe Contreras
2021-05-27 12:05                 ` Philip Oakley [this message]
2021-05-27 14:00                   ` Felipe Contreras
2021-05-27 15:12                     ` Philip Oakley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=02bbe080-cd8a-cc7d-5dbc-9231b51c4baf@iee.email \
    --to=philipoakley@iee.email \
    --cc=andre.ulrich@smail.fh-koeln.de \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=j6t@kdbg.org \
    --cc=sandals@crustytoothpaste.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).