Using Git or Mercurial, how would you know when you do a clone or a pull, no one is checking in files (pushing it)?

Question

Using Git or Mercurial, how would you know when you do a clone or a pull, no one is checking in files (pushing it)? It can be important that:

1) You never know it is in an inconsistent state, so you try for 2 hours trying to debug the code when your code is in a inconsistent state.

2) With all the framework code (such as Ruby on Rails) -- potentially hundreds of files -- if some files are inconsistent with the other, can't the rake db:migrate or script/generate controller cause some damage or inconsistencies to the code base?

Answer 1

Pulls and pushes are atomic in Git and Mercurial. It means they will never allow you get a partially pushed changesets. You will always get a whole changeset.

Update: I just thought you may be afraid "What if someone is pushing a series of changesets, and I will get some of them". Then it is all about the communication and workflow that is accepted in project.

It is often agreed that every commit to the trunk (master or how you call it) should leave the code in consistent state. If someone knows he will make changes that will create temporary inconsistencies, he should do it in a branch and if it is ready merge it to the trunk. Then trunk is brought to the branch's state in one commit so you will always see it consistent.

Update 2: As tonfa said in comment - in Mercurial push is atomic. I did some simple test in git, and pushes are atomic here too. So you do not need to fear such inconsistencies if you know that other developers push working changesets. (although earlier statements about branches are still valid).

Answer 2

When I do a pull in hg, if there are no changes, I get a:

pulling from <REPOSITORY NAME>
searching for changes
no changes found

So I know there haven't been any changes since the last time I pulled. Plus, you can always browse the repository history and see what changes have been made.

Answer 3

As others have said, commits are atomic so you wont have an issue with an inconsistency due to a partial commit.

What this answer adds to the conversation is that you have the option to add pre commit hooks that force a clean run of the test suite before the commit is allowed.

http://www.kernel.org/pub/software/scm/git/docs/githooks.html

http://mercurial.selenic.com/wiki/Hook