Hi Madhu, Johannes Sixt wrote: > On Samstag, 26. Juni 2010, Madhu wrote: > > +++ b/git-rebase--interactive.sh > > @@ -749,6 +749,7 @@ first and then run 'git rebase --continue' again." > > git symbolic-ref HEAD $HEADNAME > > ;; > > esac && > > + git-reset && > > output git reset --hard $HEAD && > > rm -rf "$DOTEST" > > exit > > No, it can't be that simple. If rebase stopped due to a conflict on a commit > that added new files, then your version of rebase --abort will leave these > new files behind as untracked. Right. The interactive rebase has to be able to differentiate between files that you added to resolve a conflict and files that you added to retain at the end of the rebase -- and the interactive rebase has no information about this. Hence, this problem can't be fixed without explicitly finding out the intent of the user. In my opinion, you should simply stash your changes before aborting the rebase instead of adding files and figuring out some complex way of expressing intent. -- Ram -- 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