![]() ![]() Furthermore, it lists only files which were modified from all parents. It shows the differences from each of the parents to the merge result simultaneously instead of showing pairwise diff between a parent and the result one at a time (which is what the -m option does). This flag changes the way a merge commit is displayed (which means it is useful only when the command is given one, or -stdin). Since the -cc option describes itself in terms of the -c option, let’s look at that too. When all hunks are uninteresting, the commit itself and the commit log message is not shown, just like in any other “empty diff” case. It implies the -c and -p options and further compresses the patch output by omitting uninteresting hunks whose the contents in the parents have only two variants and the merge result picks one of them without modification. This flag changes the way a merge commit patch is displayed, in a similar way to the -c option. If we look at the git diff-tree documentation, we can see that the -cc flag is the one that’s interesting to us. The git diff-tree command is a lower level command and if I had to guess, git show builds on top of it. Notice how much less there is there compared to the full diff of the merge commit. You can see the output of the git show command in this gist. For example:Īs I’ll show later, the -cc option is useful for finding interesting commits like this. You can use git diff to look at either side of the merge. The SHA for this commit is cc5b002a5140e2d60184de42554a8737981c846c which is pretty easy to remember but to be fair to those with drug addled brains, I’ll use cc5b002a as a shorthand to reference this commit. This commit merges their release branch into their dev branch. Let’s look at an example of such a merge commit from the SignalR project. But in most cases a merge commit has exactly two parents. In fact, a merge commit may have two or more parents as it’s possible to merge multiple branches into one at the same time. Recall that when you merge one branch into another, a new merge commit is created that points to both branches. Well my hero Russell Belfer (no blog, but he’s on Twitter) to the rescue! He works on LibGit2 so as you’d expect, he knows a thing or two about how Git works. What you really want to look at is whether there were conflicts and what shenanigans did the person have to do to resolve those conflicts. For the most part, that’s all code that’s already been reviewed and doesn’t need to be reviewed again. The problem he alludes to is that when you merge one branch into another, the diff of that merge commit will show every change since the last merge. In a recent merge commit PR that I sent, he made the following comment just before he merged my PR. However, this runs into some problems as articulated by my quotable co-worker Paul Betts. That way, someone can do a quick review to make sure the merge doesn’t break anything and merge it in. The second command uses the -b to create a new branch named merge-master-into-long-running-branch based off the current one. The first command just makes sure I’m in the long-running-branch. Git push origin merge-master-into-long-running-branch # Manually do a lot of work to resolve the conflicts and commit those changes Git checkout -b merge-master-into-long-running-branch I’m not suggesting this was the result of a bad merge conflict resolution, but you could easily see how a bad merge conflict might produce such a bug and bypass careful code review. After all, a bad merge conflict resolution could introduce or reintroduce subtle bugs that were presumed to be fixed already.Īs a great example, take a look at the recent Apple Goto Fail bug. And any time there is significant work, others should probably review that code in a pull request (PR for short). A major merge conflict may contain a significant amount of work to resolve it. Worse, merges often are not reviewed very carefully (I’ll explain why later). Often, we treat the work to resolve a merge conflict as trivial. ![]() But even so, the occasional long running branch and gnarly merge conflict are unavoidable. The impact of merge conflicts can be mitigated by doing work in small iterations and merging often. ![]() If two developers change the same line of code in different ways, someone has to figure out what the end result should be. Git can only do so much to resolve conflicts. In a fairy tale world with rainbow skittles and peanut butter butterflies, every merge would be without conflict.īut we live in the real world where it rains a lot and where merge conflicts are an inevitable fact of life. Most of the time, it merges without conflict. Git does a pretty amazing job when it merges one branch into another. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |