Olivier Marin <dkr+ml.git@xxxxxxx> writes: > The last thing that still annoy me is the --skip that refuse to skip in 3-way > merge. Perhaps we can use the "git read-tree --reset -u" thing for skip too. Hmm... We traditionally left that as something the user deliberately should do to signal --skip that the user knows he is dropping that change (by the way, so did "git-rebase"). But with fb6e4e1 (Do git reset --hard HEAD when using git rebase --skip, 2007-11-08), we run the reset upon rebase --skip, so it probably is a good idea to match it here as well. > diff --git a/git-am.sh b/git-am.sh > index 60aaa4a..864c77e 100755 > --- a/git-am.sh > +++ b/git-am.sh > @@ -202,8 +202,15 @@ then > die "previous rebase directory $dotest still exists but mbox given." > resume=yes > > - case "$abort" in > - t) > + case "$skip,$abort" in > + t,) > + git rerere clear > + git read-tree --reset -u HEAD HEAD > + orig_head=$(cat "$GIT_DIR/ORIG_HEAD") > + git reset HEAD > + git update-ref ORIG_HEAD $orig_head > + ;; Sorry, I do not quite understand what this reset after the read-tree dance is trying to do; you have already reset the index to the tree in HEAD when you cleared the change involved in the patch application with that two-tree form of read-tree. -- 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
