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

From: Piotr Krukowiecki <piotr.krukowiecki@gmail.com>
Date: Feb 19, 2011, 20:13 UTC
Message-ID: <4D602456.3020200@gmail.com>
In-Reply-To: <20110218231748.GA17836@elie>

W dniu 19.02.2011 00:17, Jonathan Nieder pisze:

Show 9 quoted lines

>>> "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 :(

Show 7 quoted lines

>> 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".

Show 5 quoted lines

> 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