# Doing a dummy or empty merge 5 messages from 2010-03-11 to 2010-03-15. Participants: Richard Lee, Randal L. Schwartz, Junio C Hamano. Thread: https://gitlist.dev/t/22984 ## Richard Lee, 2010-03-11 12:16 Subject: Doing a dummy or empty merge Message-ID: <8440EA2C12E50645A68C4AA9887166513FC480@SERVER.webdezign.local> URL: https://gitlist.dev/e/8440EA2C12E50645A68C4AA9887166513FC480%40SERVER.webdezign.local ``` 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 ``` ## Randal L. Schwartz, 2010-03-11 17:21 Subject: Re: Doing a dummy or empty merge Message-ID: <86wrxiepv3.fsf@blue.stonehenge.com> URL: https://gitlist.dev/e/86wrxiepv3.fsf%40blue.stonehenge.com In-Reply-To: <8440EA2C12E50645A68C4AA9887166513FC480@SERVER.webdezign.local> ``` >>>>> "Richard" == Richard Lee writes: Richard> At this point I want to merge this test branch into the live branch Richard> despite not having made any commits apart from deployment related Richard> changes on the test branch. I want this to be a dummy merge so that a Richard> merge is recorded into the live branch, but the contents of the live Richard> branch remain untouched. This is as if I made an empty commit on the Richard> live branch. I think you'll get what you want with a "merge -s ours" from test to live. That says that "I've looked at test, and I've looked at the parents of live, and this is how I want the result to look". Further commits on test can then be merged to live automatically using this new merge as the (initial) base. Of course, later commits after that will use subsequent bases, but that should already work the way you want. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion ``` ## Junio C Hamano, 2010-03-11 20:26 Subject: Re: Doing a dummy or empty merge Message-ID: <7vljdyzjsy.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vljdyzjsy.fsf%40alter.siamese.dyndns.org In-Reply-To: <86wrxiepv3.fsf@blue.stonehenge.com> ``` merlyn@stonehenge.com (Randal L. Schwartz) writes: >>>>>> "Richard" == Richard Lee writes: > > Richard> At this point I want to merge this test branch into the live branch > Richard> despite not having made any commits apart from deployment related > Richard> changes on the test branch. I want this to be a dummy merge so that a > Richard> merge is recorded into the live branch, but the contents of the live > Richard> branch remain untouched. This is as if I made an empty commit on the > Richard> live branch. > > I think you'll get what you want with a "merge -s ours" from test > to live. That says that "I've looked at test, and I've looked at > the parents of live, and this is how I want the result to look". > > Further commits on test can then be merged to live automatically using > this new merge as the (initial) base. Of course, later commits after > that will use subsequent bases, but that should already work the way you > want. After the above "merge -s ours", you obviously can never merge from live to test. You have declared that you favor the live configuration over the test configuration with that merge commit, and merging a branch that has that merge commit (i.e. live) into any branch (i.e. test) is your consent to be bound by that declaration. The resulting backmerge will wipe the test configuration and replace it with that from live. Not that anybody would be likely to want to merge live back to test, but I thought it is worth a warning, as people who haven't thought through what it means to make a merge commit (or more generally, any commit) can get confused. ``` ## Randal L. Schwartz, 2010-03-11 21:16 Subject: Re: Doing a dummy or empty merge Message-ID: <864okmeeyd.fsf@blue.stonehenge.com> URL: https://gitlist.dev/e/864okmeeyd.fsf%40blue.stonehenge.com In-Reply-To: <7vljdyzjsy.fsf@alter.siamese.dyndns.org> ``` >>>>> "Junio" == Junio C Hamano writes: Junio> After the above "merge -s ours", you obviously can never merge from Junio> live to test. You have declared that you favor the live configuration Junio> over the test configuration with that merge commit, and merging a Junio> branch that has that merge commit (i.e. live) into any branch Junio> (i.e. test) is your consent to be bound by that declaration. The Junio> resulting backmerge will wipe the test configuration and replace it Junio> with that from live. Very good point. But a cherry-pick would work, right? -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion ``` ## Richard Lee, 2010-03-15 18:21 Subject: RE: Doing a dummy or empty merge Message-ID: <8440EA2C12E50645A68C4AA9887166513FC532@SERVER.webdezign.local> URL: https://gitlist.dev/e/8440EA2C12E50645A68C4AA9887166513FC532%40SERVER.webdezign.local In-Reply-To: <864okmeeyd.fsf@blue.stonehenge.com> ``` >>>>> "Junio" == Junio C Hamano writes: >> After the above "merge -s ours", you obviously can never merge from >> live to test. You have declared that you favor the live >> configuration over the test configuration with that merge commit, and >> merging a branch that has that merge commit (i.e. live) into any >> branch (i.e. test) is your consent to be bound by that declaration. >> The resulting backmerge will wipe the test configuration and replace >> it with that from live. Yes I have now come across this issue. I was working on the live branch directly as it was a small change and was easier to work with the live platform. Now I don't have a way to merge the changes from the live branch into the test branch without overwriting the test configuration. >Very good point. But a cherry-pick would work, right? Yes a cherry-pick would work. But is there a "neater" way to do this, possibly using merging? I prefer merging over cherry-picking because merging will use the common ancestor so that only the succeeding commits are taken into account. After a while, keeping track of what has and has not been cherry-picked would be difficult. I get the feeling there is a better way to set out my branches/workflow. Is there a way I can have a branch for each deployment where I can merge over any changes in either direction between any two branches? Would I need some sort of central "vanilla" branch for this? ```