Hi again git-list, This is a question regarding merging following directly on from my last question about workflows. I was recommended a workflow by Jon Seymour to handle multiple deployments of the same project. In a nutshell, the workflow was to keep a main branch that reflects a generic undeployed state and keep each deployment along with the deployment artifacts in a seperate branch. I don't have a generic branch as such. It's not have the way software I was given to work on works. I do have a live/production branch. I have just created a local/test branch. So far I have made and committed and changes that enables the project to run on my local machine. At this point I want to merge this test branch into the live branch despite not having made any commits apart from deployment related changes on the test branch. I want this to be a dummy merge so that a merge is recorded into the live branch, but the contents of the live branch remain untouched. This is as if I made an empty commit on the live branch. The reason why I want to do this is that I want a point on the test branch that represents when all deployment-specific commits have been made. Any further commits from this point onwards are additional features or bug fixes that are unrelated to the deployment. So any further merges from this point onwards into the live branch will only bring over these additional features and fixes. The deployment settings on the live branch will remain untouched as I have made a 'dummy' merge already. I think a nice additional consequence would be that any resulting merge conflicts would probably indicate that I have made deployment specific commits rather than any features of bug fixes. So the question is how do a do a dummy or empty merge as described? So far I can only thing of doing a --no-commit merge, then checking out all changed files from the live branch. Is there a neater way of doing this? I assume this would be like the merge using the 'theirs' strategy, but the strategy would be used on all merge changes rather than just conflicts. Or is there a better way of implementing this workflow? Regards, Richard -- 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