GitHub Git Merge 2013, 5 Jun 2013

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Git Merge • git-imerge (Michael Haggerty)

Description

Subscribe: http://bit.ly/subgithub • Michael Haggerty describes his git-imerge tool in detail, which performs merges between git branches incrementally. If conflicts are encountered, the tool figures out exactly which pairs of commits conflict, and presents the user with one pairwise conflict at a time for resolution.

About Git Merge
Git Merge is a Git user conference, held to bring together Git users and Git developers. This May, they came together in Berlin to improve the world of Git for everyone.

A

My name's michael haggerty., I'd like to talk about git-imerge,.

A

Incremental merging for git., this was originally planned.

A

For a longer time slot, so I think I'm gonna have to go pretty quickly.

A

The two common ways of bringing two branches together would be to use "git, merge" or "git rebase.".

A

They both have big problems,, which I'm sure you're aware of.

A

I'll go through quickly. "git merge:". You have one big commit.

A

That you have to resolve all in one burst..

A

Resolving big conflicts is hard..

A

Merging is all-or-nothing. once you've started a git merge,.

A

You can't really do anything else with your repository until you've either resolved the conflict or given up and gone back.

A

To your old version., you can't record your progress.

A

You can't switch to another branch while you're in progress..

A

If you make a mistake,, you can't go back.. It's all-or-nothing.

A

There's no way to test a partially merged tree.. Once you have those merge conflict.

A

Markers in your code,, you can't build your code,.

A

You can't test it., you have to resolve the whole conflict,.

A

And then you can test. it's hard to collaborate on a merge;.

A

There's no way to push a conflicting merge to your repository.

A

So git rebase, on the other hand, is a little better in some ways.

A

And worse, in other ways.

A

For git rebase, you have to resolve each of your branch.

A

Commits with all of the commits you've made on master.

A

I'll talk about branch and master., they could be generic branches, of course,, which is better than git merge..

A

Git merge,, you have to bring all of your changes together at once.

A

rebase at least breaks it up a little bit, and I think you've noticed that that's usually easier., but rebasing is also all-or-nothing;. Once you're in the middle of a rebase,.

A

You can't use the repository for anything else., it's hard to store a rebase, that's in progress.

A

It's hard to share the work with somebody else.

A

You can't collaborate on a merge, and once you're done,, rebasing discards, history, which..

A

Is this on now? okay.

A

Rebasing, discards, the final history,, and so what you're.

A

Left with is a repository that doesn't include all of the things.

A

That have happened to it,, and that has a lot of side. Effects.

A

The main one is: it's not recommended to rebase work.

A

That's already been published,, because if somebody else has.

A

Based their work on your original branch, they're, going.

A

To be screwed when they try to rebase or merge their branch.

A

So rebasing is hostile to collaboration., I'm going to skip ahead a little bit,.

A

And then I'll come back and summarize the advantages of incremental merge,. But first I just want to give you a sketch.

A

Of what is the basic idea.

A

Suppose you want to merge a branch into master.

A

I've just drawn this in the traditional way.

A

you have some commits on master,. You have some commits on branch, and you want to bring them together.

A

The first step is just draw the diagram a little bit differently.

A

I've just drawn the branch commits down the left, side.

A

Now, one of the main problems with merge is, you've got so many changes on master,.

A

So many changes on branch, and you have to bring them together all at once.. So let's do the smallest thing possible.

A

To try to make progress towards the full merge.

A

The smallest thing is,, we just merge the very first commit on master and.

A

The very first commit on branch. now,. This is a lot easier, of course.

A

There are fewer changes. you've got a log message for each of those two changes.. You could look at the log message,.

A

See what those commits were trying to do, bring them together.

A

In fact,, it's pretty likely, there's not even gonna, be a conflict, and git can do that for you by itself, right?.

A

So this is important. at that point,. You can store that.

A

Merge commit into your repository with two parents.

A

You can tell git, "yes, I've done this merge between commit 1".

A

"And commit a, and here's the result," and git can remember.

A

That, can store it in the repository with two parents, 1 and a,.

A

And then git knows what you've done and has a true picture of what's been accomplished, so far.

A

Then you just continue.

A

This next commit is, maybe not quite so obvious, but you've.

A

Got a commit b1., it's a merge of the merge, commit that.

A

You just made, a1,, plus the branch commit b.

A

What this b1 commit includes is the change that was made in master.

A

In step 1, in commit 1,, and it includes the changes made.

A

In commits a and b on branch., but the change from commit a.

A

Is already merged together., that's already in a1.

A

So you're not going to need to worry about conflicts that were already.

A

Resolved in that first merge.

A

What you really need to do is you need to--I. Think I put.

A

Something here--you need to add the changes that were made.

A

In commit b on the branch to the state that already exists.

A

In commit a1, or equivalently, you'd need to take the changes.

A

That were originally made in master, commit 1,.

A

And apply them to the state, that's visible in commit b.

A

So,, this is the key point, is that this commit should be no harder than commit a1,.

A

Because you're bringing one change from one side,, one change from the other side, doing a pairwise merge,.

A

Pairwise conflict resolution, and then you're done.

A

when you're done,, you commit it as a merge, commit with two parents, b and a1.

A

Now, should be pretty obvious what you do.

A

You just keep continuing here.. Let me just take a characteristic,.

A

Typical commit here in the middle,, because it's a little bit less obvious,.

A

But it's really the same principle. this commit c2 is taking.

A

The change that was made in master commit number two,.

A

And adding it to the state, that's already recorded in.

A

Merge commit c1, or equivalently,. It takes the changes.

A

That were made in branch, commit c and adds them to the state.

A

That's already recorded in your merge, commit b2.

A

Is it clear?? Are there any questions?.

A

In all of these commits you're, just taking one commit from each side, you're doing a pairwise merge of those two,.

A

You have both of the original commit messages to see the intent of those two sides,. You bring them together, and you record the result.

A

Oh,, this is an important take-home message.

A

I shouldn't skip this,, I guess. oh,. I explained that already.. So here we go.

A

Now we have a problem., not all of these merges.

A

Are going to be be conflict-free., so at some point, the tool,.

A

Git-Imerge, can do all of the merges that have no conflicts, automatically.

A

At some point the user is going to have to get involved..

A

There will be some pair of commits that don't merge,.

A

That have a conflict, and then you're asked to resolve it,.

A

Similar to with the git rebase. git rebase goes "dut-dut-dut-dut;".

A

As long as it's happy,, it just keeps going.

A

When it gets to a conflict,, it presents you with a merge conflict and you resolve it.

A

You commit it and you check it. In.

A

Now you have f2,, and this is what you do.

A

You continue through the whole diagram.

A

Now,, what can you do once you've got one of these diagrams?.

A

You've done all of these incremental merges.

A

I'll. Tell you later how to make them easier and automated.

A

The fact is that one of these completed diagrams contains all of the information you might ever want to know about bringing these two branches together.

A

I'm going to show you concretely. in fact,. It knows too much information.

A

You're, probably gonna want to throw some of the information away, to avoid cluttering up your repository with it. Permanently.

A

So the first question:, where is the simple merge of branch and master?.

A

And the answer is,, this is commit g11.

A

G11,, as you can see, contains all of the incremental merges going across to master, all of the commits going down to branch.

A

They're, all together in g1., so the contents,, the tree, of g1,.

A

If you were to check it, out, is exactly the tree that you would hope to get if you merged master and branch together, directly.

A

But the picture looks different, obviously..

A

The reason is because we have too much information., but what you can do is you can discard the information of all of these internal.

A

Commits, take g11, and rewrite it to have only two parents,.

A

Namely 11 and g. once you've, rewritten it,, the other, commits.

A

Are no longer reachable;, they just get garbage-collected some time, and what you have is a merge commit.

A

It might look more familiar like this,, but topologically. It's.

A

The same thing, and the contents are exactly the same.

A

You have a merge, commit.. Here's, the next question.

A

Where is the rebase of branch onto master?.

A

Where is the result of a rebase?? Where do we find that in this diagram?.

A

The answer is,, it's the rightmost column.

A

Those commits on the rightmost column are essentially the commits a-g,.

A

Rebased over to the current tip of master.

A

And again, you can have the tool rewrite your history.

A

To look like this,, and now it looks more like a rebase., it looks as if you had done these changes a-g on.

A

The tip of master, rather than when you did actually in the past.

A

Similarly, you can find the rebase of master onto branch.

A

That's just the bottom-most row of commits.

A

By rewriting the commits,, you can transform the repository to look like this.. Once you've done that, you can.

A

Push the results., nobody will even know you've used git I-merge.. If you have already published.

A

Your original branch,, that is the a-g version of the branch,.

A

And you still want to do a sort of a rebase,, but you know you're.

A

Gonna screw over your colleagues, if you do that and commit it,.

A

There's another alternative.: you can rewrite the history.

A

To look like this., this is the same. Rebase commits that you would get if you did a normal, traditional rebase,, but each of the rebase commits.

A

Has as a second parent, the original commit from the old version of the branch, before it was rebased.

A

This is something I call rebase with history.

A

The tool can do this for you. the nice quality of it is. It keeps.

A

Both of the old and the new versions of the branch in your permanent history.

A

Anybody who's based their work on the old version of the branch can just rebase or merge like they would.

A

Normally want to do.

A

Therefore,, it makes for a version of rebase.

A

That's friendly to publishing, that you can publish.

A

Now,, just a quick word about efficiency.. The tool doesn't actually.

A

Have to do all of the incremental merges between master and branch.

A

This would be a typical scenario:.

A

You have three conflicts, marked with x's here.

A

The tool has figured out where these conflicts are,, but there's.

A

This big block of merges that it's all done., it turns out,. The tool doesn't need to do.

A

All of the intermediate merges. there's an algorithm based on.

A

Bisection that can find exactly where the conflicts are.

A

Via a heuristic, and once it knows where the conflicts are,.

A

It just fills in the boundary of the rectangle that goes to.

A

The conflict., so this rectangle e, through e6 through 6,.

A

This rectangle can all be done very quickly.

A

So,, it's not nearly as processor-intensive or resource-intensive as it might be.

A

Where are we here? a quick demo.? There is a tool, I'm working on.

A

It's still very much beta,, but it's up on github.

A

It's called git-imerge, with a dash in between,.

A

And I just wanted to show very quickly how it works.

A

you start it very much like a git merge,. You check out the branch you want to merge. To,.

A

You do git-imerge start, and then here on the right side is.

A

The branch that you want to merge into your starting branch,.

A

And you have to give the merge a name., this name: merge-branch.

A

I'll tell you why, in a moment.

A

Then the tool just works, away. dut-dut-dut-dut...it tries the.

A

Auto-Merges to do a bisect and find where the conflicts are.

A

Once it does, it uses, these auto-filling commits to outline.

A

The rectangles of the mergeable areas, and all of these.

A

Things get recorded to your repository.

A

Once it's found the border of what it can do automatically for you,.

A

It switches over to this conflict situation,, where it first shows the first and second.

A

Commits that conflicted,, but the versions that were originally.

A

From master and from branch., so the commit messages that came with these commits should explain what those commits are trying to do,, and then it asks you to fix the commit.

A

And type "continue." there's a very crude.

A

Diagram functionality in here;, it shows the state of your merge.

A

These question marks are merges that can be skipped..

A

The rectangles here are the mergeable areas,, and this.

A

Hash mark shows where the conflict is, or...there can be more than one conflict.

A

You fix the change,, add git, commit, and then type.

A

"Git-Imerge continue" and then duh-duh-duh-duh,. It goes on and on.. It might find more merges, because, as it's going.

A

It uncovers more of the diagram, and there might be more conflict.

A

But when it's done,, then you can just see a diagram again.

A

You see by the fact that the bottom-right corner is.

A

Filled in,, you know that the merge is finished.

A

Then you can get imerge-finish, and you can say what your goal is.

A

If you want a simple merge,, it'll convert it to a simple merge for you..

A

If you want a rebase, it'll, convert it to a rebase, rebase with history, and I'm going to add a couple. Other alternatives.

A

That's not so interesting.

A

So let me just summarize what I see as the advantages of this style of merging.. You only ever have to merge.

A

Conflicts that involve one commit on branch, one commit on master.

A

Small conflicts are much easier to resolve than big conflicts.

A

In fact,, big conflicts can be completely intractable.

A

I've had branches that I had to abandon because I couldn't merge them..

A

This would be a hope of rescuing some of those old branches.

A

You can see the individual commits, their commit messages and so on,.

A

And that helps you figure out how to resolve the conflict.

A

Git merge records all of the intermediate states.

A

Every time you resolve a little conflict,, you store it to your repository.

A

It's there. it's permanent. in fact,. You could push it,, you could pull it,.

A

You could share it with a colleague,. You could ask the colleague to fix a.

A

Merge conflict in his part of the code.

A

This isn't all implemented,, but it's pretty trivial, because everything's stored in the repository with the correct history.

A

It never shows the same conflict twice.

A

once you've resolved the conflict,. Git knows how that conflict resolution.

A

Can be applied to further merges., you can test every intermediate state.

A

Once you've solved one of these mini-conflicts,, you can run your test suite on it and see.. You could even tell git-imerge.

A

To run the test suite as part of its automatic search for conflicts.

A

If you're not only interested in textual conflicts that git finds for you automatically,, you could run your test suite, and if the test suite fails,, you call that a conflict too, that needs human attention.

A

If there's a problem- and you don't discover it right, away,, you could use git bisect to find which of those grid of merges.

A

Was done, incorrectly.

A

It's automated through this script., it's surprisingly fast,.

A

Thanks to git being so fast, and also because of this bisection.

A

Algorithm that makes it possible to do it. Quickly.

A

The final result can be simplified to be saved in the permanent record.

A

As a normal merge,, a normal rebase or a rebase with history.

A

I think that's all I wanted to say. if there are any questions,.

A

Then I'd be glad to...

A

This is very early, results,, still, and so I'd love to have.

A

Feedback testing and people contributing. thank you.