On Mon, 11 Apr 2011, Jonathan Nieder wrote: > Hi, > > Daniel Barkalow wrote: > > > But it's annoying that, in order > > to finish a conflicted "git cherry-pick <branch>", you currently need to > > go back and find the instruction that says to commit it yourself, with the > > option "-c <sha1>" to retain authorship and message. > > You might like v1.7.5-rc0~88^2 (Teach commit about CHERRY_PICK_HEAD, > 2011-02-19). Ah, so I'm actually proposing that we not revert that series, as far as having cherry-pick-specific state is concerned. :) On the other hand, I'd like to have the logic for using that state be in the cherry-pick implementation, rather than having commit.c need to understand merge and cherry-pick (and revert, and applying a patch from email, and...). Which is to say, there should be a core state file that ends up with "cherry-pick" in it, and revert.c has registered that it handles that, and commit.c should call the registered function to use the saved state. Also, git-rebase should be able to take advantage of the fact that other code knows how to start a cherry-pick, find that it has a conflict, tell the user, and use saved information to finish it. > > And if you want to > > abort it, you need to remember "git reset --hard HEAD" (and maybe you also > > want "git rerere clear"). > > Hm, I had assumed reset --hard (or "git reset --merge HEAD") would > take care of the "rerere clear" but it seems that indeed it doesn't. In fact, Ram's series makes sure to call both, which is how I knew. -Daniel *This .sig left intentionally blank* -- 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