Running 'commit --amend' during git rebase is almost certainly a mistake,
which causes that two consequent patches are squashed together. Moreover,
the commit message of the second commit is silently lost. It is almost
certainly not what the user expects. In that very unlikely case when you
really want to combine two patches during rebase conflict resolution,
you can do that using "git reset --soft HEAD^" followed by "git commit".
---
On Thu, Jun 26, 2008 at 08:13:03AM -0400, Theodore Tso wrote:
>
> In fact, we do this already for git-merge. Why not just do the same
> thing in the middle of a merge conflict with git-rebase?
Thank you for suggestion. I have corrected my patch to so the same as
we do in the case of git-merge conflict. MERGE_MSG is already removed
on successful commit, so the patch is very simple now.
builtin-commit.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index e3ad38b..6d1d955 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -725,6 +725,10 @@ static int parse_and_validate_options(int argc, const char *argv[],
die("You have nothing to amend.");
if (amend && in_merge)
die("You are in the middle of a merge -- cannot amend.");
+ /* no MERGE_HEAD but MERGE_MSG means a conflict during rebase */
+ if (amend && !access(git_path("MERGE_MSG"), F_OK))
+ die("You are in the middle of a rebase conflict -- "
+ "cannot amend.");
if (use_message)
f++;
--
1.5.6.60.gbc566
--
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
