Dmitry PotapovHello All,
Today I got another user complaining that git rebase interactive sometimes squashing changes without being told to do that. Studying the reflog revealed what I expected to see: the user started the process of editing of chain of patches started by "git rebase -i", and then used "git commit --amend" to correct some of them, but at some point the process of rebasing was stopped due to a conflict caused by some previous changes. The user after resolving this conflict run "git commit --amend" as he did before, without realising that this time it will squash the current patch with the previous one.
Though the user realized his mistake after my explanation of how git rebase works, I still believe it is a serious usability issue, because the same command: "git commit --amend" produces drastically different results depends on whether the rebase process stopped due to conflict or on the "edit" mark. Moreover, the commit message of second patch is getting lost as result of using "git commit --amend" in the former case.
Personally, I have avoided this issue because normally I don't use git commit --amend during rebasing unless I have to correct the commit message. Instead, I just edit files and then do "git add" on them and then run "git rebase --continue". But latest versions of git suggest you use "git commit --amend" during interactive rebasing and following this advice, it is easy to fall into this trap.
The following patch disables "git commit --amend" during rebase when the process was stopped due to conflict.
-- >8 -- From: Dmitry Potapov <dpotapov@gmail.com> Date: Wed, 25 Jun 2008 23:23:22 +0400 Subject: [PATCH] don't allow 'commit --amend' during rebase conflict resolution
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".
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com> --- builtin-commit.c | 13 ++++++++++++- 1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c index e3ad38b..d03696f 100644 --- a/builtin-commit.c +++ b/builtin-commit.c @@ -925,6 +925,17 @@ int cmd_commit(int argc, const char **argv, const char *prefix) argc = parse_and_validate_options(argc, argv, builtin_commit_usage); + strbuf_init(&sb, 0); + if (amend) + { + strbuf_addf(&sb, "%s/.dotest-merge", get_git_dir()); + if (!access(sb.buf, F_OK)) { + strbuf_addstr(&sb,"/amend"); + if (access(sb.buf, F_OK)) + die("amend not committed yet patch?"); + } + } + index_file = prepare_index(argc, argv, prefix); /* Set up everything for writing the commit object. This includes @@ -937,7 +948,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix) /* * The commit object */ - strbuf_init(&sb, 0); + strbuf_reset(&sb); strbuf_addf(&sb, "tree %s\n", sha1_to_hex(active_cache_tree->sha1));
-- 1.5.6
