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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html