Re: [PATCH] Documentation: cherry-pick does not set ORIG_HEAD

[Piotr Krukowiecki <piotr.krukowiecki@gmail.com>]

W dniu 19.02.2011 00:17, Jonathan Nieder pisze:
>>> "git reset --merge" will remove local changes marked with "git add",
>>> under the assumption that they were part of the conflict resolution
>>> and thus should be cleared away.
>>
>> Didn't know that (one probably shouldn't merge with uncommitted/local
>> changes anyway). git-reset.txt mentions it, but there's no explicit
>> warning.
> 
> Care to write a patch?

I tried but gave up :( 


>> Is it possible to recognize that you have something more than what
>> was cause by the merge/cherry-pick?
> 
> I suppose it depends what you mean.  I see at least two distinct
> problems to solve:
> 
>  A. "undo" facility to recover from an ugly cherry-pick

That's what I meant. There's a 'git merge --abort', the same should be
available for cherry-pick.

If I understand correctly, this requires changes to cherry-pick to 
set ORIG_HEAD?


> This one is what reset --merge is for.  The idea is that after
> spending a little while trying to make something good out of a
> mess, you say, "oh, bother, let me get back to where I started".

Maybe 'git cherry-pick --abort' could do 'reset --merge' internally.
You would not have to remember "ok, for merge I can do --abort, 
but for cherry pick I must do reset --merge".


> So in this case it really does make sense to back out any changes
> you marked with "git add" after the cherry-pick, since they were
> part of the messy resolution process.  If there had been any
> changes registered before the cherry-pick, the cherry-pick would
> have just failed without making a mess.

Indeed, cherry-pick won't start if there are any stashed changes. 
I wasn't aware about this.

Which is a bit 	strange: why cherry-pick behaves differently than merge?
(merge allows staged changes when merging, cherry-pick doesn't).
Shouldn't they work the same, i.e. allow merge or cherry-pick if the
changes are not conflicting?


Anyway, cherry-pick refuses to work if you have staged changes, but still
doesn't mind local unstaged changes. Which makes possible following case:

   do some local hacking, do not stage yet
   cherry-pick commit with merge conflicts
   try to resolve them, adding local changes in meantime
   give up and try to abort with 'git reset --merge'

In result your local changes will be lost. I don't know how real such
situation is, but maybe git could/should prevent it?

For example by saying "you're trying to abort merge, but it will also
revert your local changes from before the merge".
 

> A patch in flight makes "git cherry-pick" print advice for this case
> when it encounters conflicts (thanks!).

Nice :)

 

-- 
Piotr Krukowiecki