Re: Odd merge behaviour involving reverts

[Nanako Shiraishi <nanako3@lavabit.com>]

Quoting Linus Torvalds <torvalds@linux-foundation.org>:

> On Thu, 18 Dec 2008, Alan wrote:
>> 
>> What am i doing wrong here?
>
> Reverting a merge is your problem.
>
> You can do it, but you seem to have done it without understanding what it 
> causes.
>
> A revert of a merge becomes a regular commit that just undoes everything 
> that the merge did in your branch. When you then do the next merge, you'll 
> do that merge with that in mind, so now git will essentially consider the 
> previous merge to be the base line, but your revert undid everything that 
> that one brought in, so the new merge will really only contain the new 
> stuff from the branch you are merging. 
>
> So if a merge causes problems, you generally should either undo it 
> _entirely_ (ie do a 'git reset --hard ORIG_HEAD'), not revert it. 
>
> Of course, if you had already made the merged state public, or done 
> development on top of it, you can't really do that. In which case a revert 
> works, but if you want it back, you should revert the revert, not merge 
> the branch again - because what you merged last time you threw away, and 
> won't be applied again.

If I understand Alan's case correctly, I think he does not want to "undo" the revert but wants to merge an updated version of the branch, as if no mistaken merge nor its revert happened in the past.

If you revert the revert on the branch before merging, doesn't it mean that you will be merging what the older version of the branch did (that is in the revert of the revert as a single huge patch) and what the updated version of the branch wants to do?  Wouldn't that lead to a mess with huge conflicts?

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/