Re: [RFC PATCH 00/11] Sequencer Foundations
- From
Daniel Barkalow <barkalow@iabervon.org>
- Date
- Apr 11, 2011, 06:34 UTC
- Message-ID
- <alpine.LNX.2.00.1104110146550.14365@iabervon.org>
- In-Reply-To
- <20110411053819.GA6502@elie>
On Mon, 11 Apr 2011, Jonathan Nieder wrote:
Show 11 quoted lines
> 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.
Show 6 quoted lines
> > 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*