Thread (35 messages) 35 messages, 5 authors, 2016-06-15

Re: [RFC PATCH 00/11] Sequencer Foundations

From: Daniel Barkalow <hidden>
Date: 2016-06-15 22:51:01

On Mon, 11 Apr 2011, Jonathan Nieder wrote:
Hi,

Daniel Barkalow wrote:
quoted
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.
quoted
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*
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help