Re: [PATCH v2 2/4] Documentation: warn prominently against merging with dirty trees
- From
Jonathan Nieder <jrnieder@gmail.com>
- Date
- Jan 10, 2010, 04:49 UTC
- Message-ID
- <20100110044949.GA8974@progeny.tock>
- In-Reply-To
- <e330d8ca1a9ec38ce40b0f67123b1dd893f0b31c.1263081032.git.trast@student.ethz.ch>
Thomas Rast wrote:
Show 10 quoted lines
> 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