Re: [DRAFT] Branching and merging with git

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

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.