Working on a project with a couple of classmates, and I've noticed that we get a lot of partial commits which are then corrected:

Rev 249 Log: committing change foo, yeah!
Rev 250 log: oh dear, forgot these files!
Rev 251 log: oh my, how could I possibly forget another file in the *same* change?

The obvious answer is to be more careful. But as of 2011, programmers are still (almost) human, and are error prone. The problem is that this causes ambiguity when reverting or merging. Do we leave them there? Do we modify the commit history?


You could use continuous integration, but it seems overkill for a class project.

If using your own server, you can run scripts (called hooks in SVN) before accepting a build. So you could do a simplified continuous integration that runs a command line build on the server before allowing the commit. Or devise a custom script that checks for missing files (by parsing makefiles or Visual projects or whatever you use).

  • Thanks. The reason I accepted this and not the at the moment top-voted answer is that this way trumps the human errors that eventually creep in - even though both together is of course ideal.
    – Max
    May 26 '11 at 6:09
  • Oh and I suggested this as I knew many people were going to mention DCVS, although I think a good use of a DCVS (git, Hg come to mind as 'mature') use local commits + shared repos could help a lot... IF people take a good care. The script approach is sure safer :)
    – jv42
    May 27 '11 at 11:41

Get your developers into the habit of doing these four easy commit steps to keep that from happening:

  • Do your project's equivalent of make clean.
  • Do your version control system's equivalent of diff from the top of the tree that was checked out.
  • Go through the results and check that each change is what you think it is (i.e., that no unrelated changes were included while working on this one).
  • Commit everything from the top of the tree.

I would suggest that whoever has made the mistake on the commit gets to handle any merge pain. You shouldn't modify the commit history - it's there to track what changes were in what revision.

If this happens a lot then get people to commit to a user branch first and do a clean checkout and build before merging their changes back into trunk.


You could use a VCS that lets you (cough) "amend" earlier commits.

git isn't the answer to EVERY version control question, but it's certainly the answer to many of them.


If you use git and you haven't pushed to the server yet, you can use rebase to rewrite those commits and squash all the changes into one commit.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.