Git – Why not commit unresolved changes

dvcsgitmercurialversion control

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?

Best Answer

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).

Related Solutions

How to Commit In-Progress Refactoring in Git

The git merge --squash command allows you to create a single commit on top of the current branch whose effect is the same as merging another branch. The command updates the working tree and stages the changes in the index, so all you have to do next is commit:

git checkout master
git merge --squash cleanup
git commit -m "Merge cleanup branch"

The git rebase -i command can also squash commits but requires more work.

Version Control – Is It Ever OK to Commit Non-Working Code?

One of the branching philosophies (section Developing Branching Strategy and Codeline Policy in Advanced SCM Branching Strategies - also read Perforce Best practices, its a pdf but goes into some other details) is that you branch on incompatabile policy.

A codeline policy specifies the fair use and permissible check-ins for the codeline, and is the essential user’s manual for codeline SCM. For example, the policy of a development codeline should state that it isn’t for release; likewise, the policy of a release codeline should limit changes to approved bug fixes. The policy can also describe how to document changes being checked in, what review is needed, what testing is required, and the expectations of codeline stability after check-ins. A policy is a critical component for a documented, enforceable software development process, and a codeline without a policy, from an SCM point of view, is out of control.

(from Perforce Best Practices)

Say you have the branches 'release' (or 'master') from which a release is built and 'trunk' (or 'dev') where developers check in working code. These are the policies of the branches. Noting the 'working code' is part of the 'dev' branch policy, one should never commit broken code to the dev branch. Often there are things such as CI servers hooked up to these branches and checking in broken code into dev could mess up everyone's branch and break the build.

However, there are times when it is appropriate to check in partial code that doesn't work. In these instances, one should branch - an incompatible policy with trunk. In this new branch, one can decide the policy ('broken code is ok') and then commit code to it.

There is one simple rule to determine if a codeline should be branched: it should be branched when its users need different check-in policies. For example, a product release group may need a check-in policy that enforces rigorous testing, whereas a development team may need a policy that allows frequent check-ins of partially tested changes. This policy divergence calls for a codeline branch. When one development group doesn’t wish to see another

(from Perforce Best Practices)

Realize that this is coming from a central server based SCM with a strong corporate mindset. The core idea is still good. These are often thought of implicitly - you don't check in untested dev code into the release branch. Thats a policy.

So branch, say that this branch can have broken code and commit away.

Best Answer

Related Solutions

How to Commit In-Progress Refactoring in Git

Version Control – Is It Ever OK to Commit Non-Working Code?

Related Topic