|Date: Mon, 28 Jun 2010 11:05:17 +0200 |From: Ramkumar Ramachandra <artagnon@xxxxxxxxx> |Cc: Madhu <enometh@xxxxxxxx>, git@xxxxxxxxxxxxxxx |Content-Type: text/plain; charset=us-ascii |Content-Disposition: inline | |> 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. Wrong. Rebase has to be able to differentaiate between two cases 1. when there is a conflict, and the user is prompted to fix it, and then continue with a git-add, git-commit, and git-rebase --continue and 2. when the user is given a commit, which he is asked to git-commit --amend, and then git-rebase --continue Rebase is already aware of when each situation occurs. |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. This does not make sense. -- Madhu -- 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