Prompt for confirmation when discarding staged files in a merge context

[chrispitude]

Sometimes writers see unfamiliar or unexpected files staged in the Git Staging view. For example,

• A refactoring or search/replace operation had wider-than-expected consequences.
• The Git plugin crashed during a pull, leaving files in a desynchronized state.

We teach our writers that if they're ever uncertain of changes they see in the staging view, doing a Discard will restore the repo to a safe state.

However, we have repeatedly run into issues where writers incorrectly seek this safety during merge conflict resolution. Consider the following scenario:

image.png

In this scenario, conflict resolution shows the following:

image.png

where the staged files ("file_upstream.txt" here) represent all work that all other writers have been working on. In this case, if the writer discards these staged files because they were unfamiliar, then the outcome of the merge is to discard all that work from all other writers.

This has happened to us multiple times, despite emails and training slides describing how the conflict resolution process works. One writer explained that because they were in conflict resolution, they thought that discarding unfamiliar files was resolving conflicts.

As our local Oxygen/Git person, I understand what staged files represent in a merge context. However, most of our writers have only a basic knowledge of pushing and pulling, and the detailed mechanics of Git conflict resolution are not intuitive to them (in part because it happens infrequently).

The issue is that the meaning of "discard" itself changes. Normally "discard" means "discard my uncommitted work and get me back to safety". But in a merge context, "discard" means "discard someone else's committed work".

It would be helpful if the Git plugin would issue a dialog box for Discard in a merge context, perhaps something like:

In a merge context, this operation would discard already-committed work from %s. Are you sure you want to discard these commits?

where %s could be $origin/$branch or a similar suitable string that identifies "theirs" versus "ours". (For rebase conflicts, this might identify the commits as being from "<local>/$branch" or something like that.)

A testcase is included. To run,

1. Extract the testcase.
2. Go to the "git_conflict_local_branches" directory.
3. Open the Oxygen project file.
4. Load the repo in the Git Staging view.
5. In the Git Branch Manager, merge "upstream" into "local".

This testcase uses two local branches to create a conflict. I also tried using filesystem cloning to replicate an upstream/local conflict, in the "git_conflict_merge_pull" directory. However, the Oxygen Git plugin does not seem to understand repos cloned from a filesystem path, and so I was not able to do a pull from upstream to induce the conflict. (I can do so via the Git command line, but that does not reproduce the conflict scenario in Oxygen.)

(In each directory, a "make_git.sh" script recreates the starting point.)

git_conflict.zip

[alex_jitianu]

Hello Chris,

Thank you for the detailed explanation and samples. I've added an improvement request and we will try to implement it on the short term. Git concepts and workflows can be challenging at time, so I agree that we should try and help writers better understand the effect of some actions.

Best regards,
Alex

[chrispitude]

Thanks Alex! I appreciate the consideration.

Git has a reputation for being tricky to use, as evidenced by the name itself:

https://en.wikipedia.org/wiki/Git#Naming

Any guidance through the tricker aspects to help novice users harness its power is valuable!