Why not commit unresolved changes?

Question

In a traditional VCS, I can understand why you would not commit unresolved files because you could break the build. However, I don't understand why you shouldn't commit unresolved files in a DVCS (some of them will actually prevent you from committing the files).

Instead, I think that your repository should be locked from pushing and pulling, but not committing.

Being able to commit during the merging process has several advantages (as I see it):

• The actual merge changes are in history.
• If the merge was very large, you could make periodic commits.
• If you made a mistake, it would be much easier to roll back (without having to redo the entire merge).
• The files could remain flagged as unresolved until they were marked as resolved. This would prevent pushing/pulling.

You could also potentially have a set of changesets act as the merge instead of just a single one. This would allow you to still use tools such as git rerere.

So why is committing with unresolved files frowned upon/prevented? Is there any reason other than tradition?

Answer 1

The biggest issue that I can see is that it creates a window of commits where things are half-merged and (probably) not working correctly. When you push the final set of local commits, all of those intermediate commits will also apear for everyone else. In ideal world, I should be able to pull any commit and the code should work. If you start committing in the middle of merges, the state of the code isn't well-defined.

One thing you could do is make local commits to your merge, and then bundle them into one big commit when you push (though I'm not sure how(if?) any vcs support this). While this might yield some of the benefits you mentioned, I'm not sure it's worth the extra complexity (we're already dealing with a fairly confusing and complex area).

Answer 2

I am most familiar with Git, so I will be answering for that perspective.

I don't see a reason why you or any good VCS would want to allow committing an unmerged file, particularly if it was code. You need to keep the repository in a consistent state, and what you are suggesting would violate commit atomicity. Many VCS's physically change the file to show where the conflicts are - Git, SVN, and CVS use >>>> <<<< type markers. In a VCS with atomic repository-level commits and merges, you would just have created a node that makes no sense to anyone but you. In software development, your project couldn't build. In a group's document, no one knows which changes are correct.

Now, Git provides some tools that could ease this, were the type of commit you suggest allowed. You could squash all you merge commits together before you pushed, for example. That winds up being the same as a typical merge commit.

Specific concerns about your list of benefits:

1. The actual merge changes are in history. Why do you need extra information? DVCS's are very good about limiting conflicts to confined areas. Once you choose which changeset to keep, comparing the merge commit node's copy to the previous copy will give you exactly this.
2. If the merge was very large, you could make periodic commits. This is a valid concern, but you shouldn't ever get here in the first place. Branches should constantly be pulling in upstream changes just so this won't ever happen. Tools like rebase or cherry-pickking one commit at a time can also assist you here in some situations.
3. If you made a mistake, it would be much easier to roll back (without having to redo the entire merge). See above - your conflicts shouldn't become this unmanagable.

The only way this suggestion could work is if the branch was if the whole merge was atomic - you could see a series of commits, but they would be merely steps in a larger merge commit that had to be treated as one node in the commit tree. I don't think any current VCS has support for this type of workflow, and I don't think it is necessary.

Answer 3

My main experience lies with Mercurial, although I also use git sporadically.

Mercurial doesn't disallow you to commit unresolved files, it just discourages you. Same deal with pushing before pulling changes that you don't have.

All you need to do in Mercurial is, once you have the files the way you want to commit them:

hg resolve --mark --all
hg commit -m "I'm such a rebel"

--mark will... mark files as resolved without prompting you with the merge tool. --all will take care of selecting all files mark with conflicts.

If you want to push without pulling (and consequently having to merge other's changes) do like a Jedi:

hg push --force

Next guy who pulls will get +1 head (no pun intended)

I'm sure there is a way to do the same stuff with Git (although it probably is more convoluted).

Answer 4

When I merge in git, I immediately commit all changes (including the merge conflicts). Then, in my next commit(s), I resolve the merge conflicts via a text editor. After the conflicts are resolved, I then Push if desired.

Honestly I don't understand why others don't do it this way, or git doesn't enforce it.

• The "merge commit" is now a clean history of exactly what needed to be merged.
• The following commit(s) show exactly what you did to resolve the merge conflicts.
• When you Push, conflicts are by then resolved and the build unbroken at the tip of the branch.
• At any point, if you screw up the conflict resolution, you can simply revert to one of the "post merge" commits and try again.

A huge drawback of the standard workflow of resolving conflicts before committing is that changes from your local copy can sneak in. The additions are hidden from code review by the massive merge diff, so you don't notice that you've accidentally committed an API key or etc.

My workflow described above avoids this local copy issue, and also allows code reviewers to examine (only) the details of your merge resolution in a commit diff that looks exactly like a standard commit diff.

Answer 5

I think it's best to push small changes and push often, when it's possible(and of course it isn't always), and don't commit code that doesn't build, or is half complete(we all make mistakes, but don't do it on purpose). I also come from git, and one of the best things I think is the fact that you can have a workable copy of the repo on your desktop...which you can then modify to your hearts content. When your big changes are done, send it away.

Doing a lot of open source with git the biggest frustration for me was getting half done code plopped into the repo, and trying to do a build, but couldn't, because the guy did half the work and said "I'm busy now, I'll finish it in a week". So I'd end up having to scrap it(which would annoy the guy), or take the time to finish and completely integrate it.

I guess from my perspective, keep the half ass stuff locally, send the good stuff over the wire.

Answer 6

Don't be a slave to your tools.

The goal of a VCS is to enable you to do your job. Your job is not to keep a pristine local repository, your job is to write code. If committing early and often locally lets you work better, do it.

You shouldn't, however, push broken code upstream.

Answer 7

Because fundamentally its a bad idea - it will lead you to a repository that is in a parlous state (and its rash to assume that you'll ever push anywhere, although one would argue that you should always have at least one copy).

I can see that in the case of a large/complex merge you might want to save your work in progress and to establish a reference point but you'd still be leaving the system in a messed up state that needs to be resolved.

And there are alternatives - you have the option to merge from earlier than the head - which may well give you the ability to adapt to changes without epic merges (or at least with larger merges that are easier to comprehend).

This is the case I find git's rebase is particularly useful (subject to the usual caveats about rebasing) because you're replaying your changes atop the current state you get to fix conflicts in smaller pieces.