The thing is that I want my 'master' branch' to reflect what is in the 'master' repo - we are using another versioning control system than git for the master for the moment. I want to be able to switch to the master at any moment, do an update there with the primary versioning system in use, and get all others commits and merge down to my branch from time to time. It seems to me that this behaviour corrupts the master branch, reflecting a change in the master branch that I did not want or expect. so I suppose the correct work flow would to be *ALWAYS*, commit on the branch you are on before switching to another branch? I think this would solve the problem. This just seems a bit odd. I did not commit on the branch, I switched and it's on the master now. At any rate, I can work with it, just need to know the correct work flow I should take before switching to another branch, and that seems to be *ALWAYS* commit before switching to get the expected behaviour that seems normal to me. -- View this message in context: http://git.661346.n2.nabble.com/Git-Unexpected-behaviour-tp6986736p6986770.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html