The following is an easy mistake to make for users coming from version
control systems with an "update and commit"-style workflow.
1. git pull
2. resolve conflicts
3. git pull
Step 3 overrides MERGE_HEAD, starting a new merge with dirty index.
IOW, probably not what the user intented. Instead, refuse to merge
again if a merge is in progress and present the user with his options.
"git reset --hard" is not suggested, because it potentially removes
changes unrelated to the merge (if the work tree was dirty prior to
the merge).
Reported-by: Dave Olszewski <cxreg@xxxxxxxxx>
Signed-off-by: Clemens Buchacher <drizzd@xxxxxx>
---
Ok, since I'm not seeing any more objections. Here's the code.
Clemens
builtin-merge.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index 0b58e5e..8169ded 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -834,10 +834,16 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
struct commit_list *common = NULL;
const char *best_strategy = NULL, *wt_strategy = NULL;
struct commit_list **remotes = &remoteheads;
+ int unmerged;
setup_work_tree();
- if (read_cache_unmerged())
- die("You are in the middle of a conflicted merge.");
+ unmerged = read_cache_unmerged();
+ if (unmerged || file_exists(git_path("MERGE_HEAD")))
+ die("You are in the middle of a %smerge. To complete "
+ "the merge %scommit the changes. To abort, "
+ "use \"git reset HEAD\".",
+ unmerged ? "conflicted " : "",
+ unmerged ? "resolve conflicts and " : "");
/*
* Check if we are _not_ on a detached HEAD, i.e. if there is a
--
1.6.3.1.147.g637c3
--
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