Hi Martin, Martin von Zweigbergk writes: > A long time ago I said I wished that 'git rebase --abort' would move > back to the where HEAD was when the rebase was initiated, instead of > moving back to the branch that was about to be rebased (which may be > different for "git rebase $upstream $branch"). I think Junio then > hinted that he sometimes wished that he could abort rebase without > moving to anywhere else at all, which is what this patch implements. I > don't feel strongly about this patch, but I would probably also use > this subcommand once in a while. However, maybe the greatest value in > it is that we don't have to tell users to mess with the .git > directory? Interesting. Yes, I usually remove the state file by hand too. In view of "git rebase --interactive" being a porcelain command, I don't know if it's alright to drop the user into a detached HEAD state. > I used "rm -r" without -f to match how it is done in --abort, but > maybe -f should be used? That is what we recommend to the end-user to > use today. If you've verified that a rebase is already in progress, I don't see the point of using '-f'. Otherwise, it should error out and say that "no rebase is in progress", like the other command-line options currently do. > A difference from --abort is that --discard does not clear > rerere. Need this be mentioned in the documentation? It depends on what you're expecting the user to do in this detached HEAD state, no? > I have not been involved in Ramkumar's work on the sequencer to know > if and how this might impact it. It'll have no impact on the Sequencer work. Thanks. -- 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