Re: [PATCH v2 2/4] Documentation: warn prominently against merging with dirty trees

[Jonathan Nieder <jrnieder@gmail.com>]

Thomas Rast wrote:

> diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
> index 4896587..3277f4e 100644
> --- a/Documentation/git-merge.txt
> +++ b/Documentation/git-merge.txt
> @@ -22,6 +22,10 @@ The second syntax (<msg> `HEAD` <commit>...) is supported for
>  historical reasons.  Do not use it from the command line or in
>  new scripts.  It is the same as `git merge -m <msg> <commit>...`.
>  
> +*Warning*: Running 'git-merge' with uncommitted changes is
> +discouraged:

Is this true?  The 'git reset' manual page gives an example of something
I end up doing pretty often:

| Undo a merge or pull inside a dirty work tree
|
|         $ git pull                         (1)
|         Auto-merging nitfol
|         Merge made by recursive.
|          nitfol                |   20 +++++----
|          ...
|         $ git reset --merge ORIG_HEAD      (2)
|
|     1. Even if you may have local modifications in your working tree, you
|     can safely say "git pull" when you know that the change in the other
|     branch does not overlap with them.
|     2. After inspecting the result of the merge, you may find that the
|     change in the other branch is unsatisfactory. Running "git reset
|     --hard ORIG_HEAD" will let you go back to where you were, but it will
|     discard your local changes, which you do not want. "git reset --merge"
|     keeps your local changes.

> while possible, it leaves you in a state that is hard to
> +back out of in the case of a conflict.
> +

Oh, that is a problem.  Maybe 'git merge' should refuse to merge
unless told otherwise, if there is a dirty index and there might be
conflicts.

In other words, would it be possible to fix this without relying on
people to look at the documentation?

Jonathan