Junio C Hamano <junkio@xxxxxxx> writes:
> 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@xxxxxxxxxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html