Re: [PATCH v2] Make cherry-pick use rerere for conflict resolution.

From: Johannes Sixt <j.sixt@viscovery.net>
Date: Aug 12, 2008, 07:02 UTC
Message-ID: <48A1356D.6020200@viscovery.net>
In-Reply-To: <alpine.DEB.1.00.0808111748220.24820@pacific.mpi-cbg.de.mpi-cbg.de>

Johannes Schindelin schrieb:

Show 7 quoted lines

> On Mon, 11 Aug 2008, Johannes Sixt wrote:
>> If the reversal is part of a topic branch that you rebase at least once, 
>> then you want to have the resolutions recorded, don't you?
> 
> That is not the revert we are talking about.  The revert we are talking 
> about is a literal "git revert <commit>".  Not a replay of a commit (that 
> might have been a revert originally).

You are right. My example misses the point.

Another example is when you have to repeat the revert, say, you find out you did it on the wrong branch. When you repeat the 'git revert' on the correct branch, you want to have the resolutions replayed.

> I am a little worried that these reverts (being negative changes) could 
> interfer with the common operation: positive changes.  Although I haven't 
> been able to come up with a scenario where the recorded revert would 
> actively be wrong in a subsequent rebase/cherry-pick.

I think that your worries are not justified. A 'git revert' is not a "negative" change; it a change like any other. 'git revert' is just a short hand for a more sequence of diff+apply+commit.

-- Hannes