Hi Sverre, Junio and Jonathan, Sverre Rabbelier writes: > Isn't this the kind of usecase we added 'git reset --merge' for? Yes, I can see that now. Junio Hamano writes: > Even if you dropped the unconditional "rerere clear" from the patch, I am > not sure what this new feature buys us. Some people would want the rerere > cache cleared, some others don't. "revert --abort" will forever be to > aborting revert and restoring some but not all the parts of the operation > the user wants to be undone, as you cannot satisfy everybody. ÂSo I am a > bit puzzled why you thought this was even a good idea to begin with. It's actually very specific to the way I work/ think -- I would have expected an abort to go back in time, and make it look like the operation wasn't performed in the first place. My normal workflow: I make my changes, create a "fixup!" commit, abort, and cherry-pick that commit from my reflog. Yes, I use "reset --hard" a lot, and yes, it's a very powerful hammer. I see now that this probably doesn't fit everyone's usecase. So the changes I propose are: 1. Don't rerere clear. We can probably document this fact somewhere, and hint the user about this during the time of abort. 2. Use reset --merge as Sverre suggested. I'll think about this workflow and post a patch soon. Jonathan Nieder writes: > I have some changes to files that did not participate in the automatic > cherry-pick: > > Â1. for unrelated reasons, I bumped the version number in the Makefile > Âas a reminder not to forget later, without commiting it or marking > Âwith "git add"; > > Â2. I (manually) moved a declaration to a different header file to > Âreflect differences between the codebase at the time of foo^ and HEAD, > Âto get it to compile. ÂWhich works, so I mark it with "git add" for > Âincorporation into the corrected cherry-pick commit. > > With "git reset --merge", (1) is left alone, while (2) is backed out, > unmerged entries are of course clobbered, and hazy cases in which I > make some changes, "git add", and then make more changes without "git > add" cause the operation to error out. ÂIt would be nicer if git could > read my mind, but at first glance this seems like an okay second-best. Thanks for the excellent explanation. I'll think about this workflow for a while before posting another iteration of this patch. -- 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