On Wed, Oct 31, 2007 at 09:12:06PM +0000, Johannes Schindelin wrote: > Hi, > > On Wed, 31 Oct 2007, Sergei Organov wrote: > > > Yes, and that's the problem. Why 'git --continue' didn't just skip this > > patch that *already became no-op* after conflict resolution and forced > > me to explicitly use 'git --skip' instead? > > Isn't that obvious? To prevent you from accidentally losing a commit. That would make sense to me if this was a mistake that could easily happen. I'd assumed that in the case of a conflict that stopped the rebase process, the index and working tree are always left dirty, so that if they both agree with the HEAD at the time of commit, then it's because the user explicitly made them that way. I ran into the same confusion as the original poster when starting to use rebase, so I suspect it's common. --b. - 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