Junio C Hamano <junkio@cox.net> writes:

quoted text
> If you want an esoteric topic for an introductory documentation,
> it would be more useful to talk about evil merges (an evil merge
> is a merge commit whose result does not match any of its
> parents).  A good example is found in
>
> 	git show v1.0.0

I actually remembered a better one.

        Subject: Necessity of "evil" merge and topic branches
        Date: Wed, 17 May 2006 23:25:55 -0700
        Message-ID: <7vy7wz6e8c.fsf@assigned-by-dhcp.cox.net>

This talks about a real-world evil merge and the reason why it
was necessary, and speculates a possible way to make life
easier.  I actually later used the "third branch to remember the
evil merge between two topics" technique I talked about in the
message to merge in another pair of topics, and it turned out
that it worked rather well.

There were two logically independent topics:

 - lt/setup.  Two commits, changing the calling convention of
   setup_git_directory() function -- the final tip of the topic
   was at a633fca0.

 - js/mv.  Three commits, making git-mv a built-in after
   refactoring some code from other parts of the system -- the
   final tip of the topic was at ac64a722).

They were not "obviously correct" when they started, so a topic
branch was used for each.  They had textually and semantically
some conflicts, and if they were to progress at different paces,
there was a need for an evil merge when the later one is merged
to master.

So I created another branch to merge the two topics together and
resolved their conflicts while my reading of their code were
still fresh.

	git checkout -b __/setup-n-mv js/mv
        git pull . lt/setup
	git checkout next
        git pull . __/setup-n-mv

Later js/mv became ready to be merged first.  So I merged it to
'master'.

	git checkout master
        git pull . js/mv

I was planning to cook lt/setup a bit longer but eventually
decided to merge it to 'master' as well after a short while.

	git checkout master
        git pull . __/setup-n-mv

I could have pulled lt/setup into master but then I would have
had to resolve the conflict between the two branches.  Since I
recorded the resolution earlier by making the merge, and pulled
that branch (which contained all of lt/setup already) into
'master', I did not have to remember what I need to adjust when
I did so.  If lt/setup had further updates on its own after the
"third branch __/setup-n-mv" was made, I would have then pulled
the tip of lt/setup into 'master' to complete the merge, and
that would have also resulted in non-conflicting simple merge.

This would have worked equally well if lt/setup were to graduate
first.

This might look too complex at the first look, but I thought it
might be an interesting topic in the "hints for managing your
topic branches" section.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html