{"thread":{"id":"22984","subject":"Doing a dummy or empty merge","startedAt":"2010-03-11T12:16:09Z","lastAt":"2010-03-15T18:21:55Z","messageCount":5,"participants":["Richard Lee","Randal L. Schwartz","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"136580","messageId":"8440EA2C12E50645A68C4AA9887166513FC480@SERVER.webdezign.local","threadId":"22984","inReplyTo":null,"subject":"Doing a dummy or empty merge","fromName":"Richard Lee","fromEmail":"richard@webdezign.co.uk","sentAt":null,"receivedAt":"2010-03-11T12:16:09Z","isPatch":false,"sender":{"key":"richard@webdezign.co.uk","avatar":"https://gravatar.com/avatar/36c0bc285b2d30baa54ed2e1488161fd27a4a4a8128836a673b66204ab08c9b7?d=mp&s=160"},"body":"Hi again git-list,\n\nThis is a question regarding merging following directly on from my last\nquestion about workflows.\n\nI was recommended a workflow by Jon Seymour to handle multiple\ndeployments of the same project. In a nutshell, the workflow was to keep\na main branch that reflects a generic undeployed state and keep each\ndeployment along with the deployment artifacts in a seperate branch.\n\nI don't have a generic branch as such. It's not have the way software I\nwas given to work on works. I do have a live/production branch.\n\nI have just created a local/test branch. So far I have made and\ncommitted and changes that enables the project to run on my local\nmachine. \n\nAt this point I want to merge this test branch into the live branch\ndespite not having made any commits apart from deployment related\nchanges on the test branch. I want this to be a dummy merge so that a\nmerge is recorded into the live branch, but the contents of the live\nbranch remain untouched. This is as if I made an empty commit on the\nlive branch.\n\nThe reason why I want to do this is that I want a point on the test\nbranch that represents when all deployment-specific commits have been\nmade. Any further commits from this point onwards are additional\nfeatures or bug fixes that are unrelated to the deployment. So any\nfurther merges from this point onwards into the live branch will only\nbring over these additional features and fixes. The deployment settings\non the live branch will remain untouched as I have made a 'dummy' merge\nalready.\n\nI think a nice additional consequence would be that any resulting merge\nconflicts would probably indicate that I have made deployment specific\ncommits rather than any features of bug fixes.\n\nSo the question is how do a do a dummy or empty merge as described? So\nfar I can only thing of doing a --no-commit merge, then checking out all\nchanged files from the live branch. Is there a neater way of doing this?\nI assume this would be like the merge using the 'theirs' strategy, but\nthe strategy would be used on all merge changes rather than just\nconflicts.\n\nOr is there a better way of implementing this workflow?\n\nRegards,\n\nRichard\n"},{"id":"136610","messageId":"86wrxiepv3.fsf@blue.stonehenge.com","threadId":"22984","inReplyTo":"8440EA2C12E50645A68C4AA9887166513FC480@SERVER.webdezign.local","subject":"Re: Doing a dummy or empty merge","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2010-03-11T17:21:20Z","receivedAt":"2010-03-11T17:21:20Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Richard\" == Richard Lee writes:\n\nRichard> At this point I want to merge this test branch into the live branch\nRichard> despite not having made any commits apart from deployment related\nRichard> changes on the test branch. I want this to be a dummy merge so that a\nRichard> merge is recorded into the live branch, but the contents of the live\nRichard> branch remain untouched. This is as if I made an empty commit on the\nRichard> live branch.\n\nI think you'll get what you want with a \"merge -s ours\" from test\nto live. That says that \"I've looked at test, and I've looked at\nthe parents of live, and this is how I want the result to look\".\n\nFurther commits on test can then be merged to live automatically using this\nnew merge as the (initial) base. Of course, later commits after that will use\nsubsequent bases, but that should already work the way you want.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nSmalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.\nSee http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion\n"},{"id":"136618","messageId":"7vljdyzjsy.fsf@alter.siamese.dyndns.org","threadId":"22984","inReplyTo":"86wrxiepv3.fsf@blue.stonehenge.com","subject":"Re: Doing a dummy or empty merge","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-03-11T20:26:37Z","receivedAt":"2010-03-11T20:26:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"merlyn@stonehenge.com (Randal L. Schwartz) writes:\n\n>>>>>> \"Richard\" == Richard Lee writes:\n>\n> Richard> At this point I want to merge this test branch into the live branch\n> Richard> despite not having made any commits apart from deployment related\n> Richard> changes on the test branch. I want this to be a dummy merge so that a\n> Richard> merge is recorded into the live branch, but the contents of the live\n> Richard> branch remain untouched. This is as if I made an empty commit on the\n> Richard> live branch.\n>\n> I think you'll get what you want with a \"merge -s ours\" from test\n> to live. That says that \"I've looked at test, and I've looked at\n> the parents of live, and this is how I want the result to look\".\n>\n> Further commits on test can then be merged to live automatically using\n> this new merge as the (initial) base. Of course, later commits after\n> that will use subsequent bases, but that should already work the way you\n> want.\n\nAfter the above \"merge -s ours\", you obviously can never merge from live\nto test. You have declared that you favor the live configuration over the\ntest configuration with that merge commit, and merging a branch that has\nthat merge commit (i.e. live) into any branch (i.e. test) is your consent\nto be bound by that declaration. The resulting backmerge will wipe the\ntest configuration and replace it with that from live.\n\nNot that anybody would be likely to want to merge live back to test, but I\nthought it is worth a warning, as people who haven't thought through what\nit means to make a merge commit (or more generally, any commit) can get\nconfused.\n"},{"id":"136622","messageId":"864okmeeyd.fsf@blue.stonehenge.com","threadId":"22984","inReplyTo":"7vljdyzjsy.fsf@alter.siamese.dyndns.org","subject":"Re: Doing a dummy or empty merge","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2010-03-11T21:16:58Z","receivedAt":"2010-03-11T21:16:58Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Junio\" == Junio C Hamano writes:\n\nJunio> After the above \"merge -s ours\", you obviously can never merge from\nJunio> live to test. You have declared that you favor the live configuration\nJunio> over the test configuration with that merge commit, and merging a\nJunio> branch that has that merge commit (i.e. live) into any branch\nJunio> (i.e. test) is your consent to be bound by that declaration. The\nJunio> resulting backmerge will wipe the test configuration and replace it\nJunio> with that from live.\n\nVery good point. But a cherry-pick would work, right?\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nSmalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.\nSee http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion\n"},{"id":"136862","messageId":"8440EA2C12E50645A68C4AA9887166513FC532@SERVER.webdezign.local","threadId":"22984","inReplyTo":"864okmeeyd.fsf@blue.stonehenge.com","subject":"RE: Doing a dummy or empty merge","fromName":"Richard Lee","fromEmail":"richard@webdezign.co.uk","sentAt":null,"receivedAt":"2010-03-15T18:21:55Z","isPatch":false,"sender":{"key":"richard@webdezign.co.uk","avatar":"https://gravatar.com/avatar/36c0bc285b2d30baa54ed2e1488161fd27a4a4a8128836a673b66204ab08c9b7?d=mp&s=160"},"body":">>>>> \"Junio\" == Junio C Hamano writes:\n\n>> After the above \"merge -s ours\", you obviously can never merge from\n>> live to test. You have declared that you favor the live\n>> configuration over the test configuration with that merge commit, and\n>> merging a branch that has that merge commit (i.e. live) into any\n>> branch (i.e. test) is your consent to be bound by that declaration.\n>> The resulting backmerge will wipe the test configuration and replace\n>> it with that from live.\n\nYes I have now come across this issue. I was working on the live branch\ndirectly as it was a small change and was easier to work with the live\nplatform. Now I don't have a way to merge the changes from the live\nbranch into the test branch without overwriting the test configuration.\n\n>Very good point. But a cherry-pick would work, right?\n\nYes a cherry-pick would work. But is there a \"neater\" way to do this,\npossibly using merging? I prefer merging over cherry-picking because\nmerging will use the common ancestor so that only the succeeding commits\nare taken into account. After a while, keeping track of what has and has\nnot been cherry-picked would be difficult.\n\nI get the feeling there is a better way to set out my branches/workflow.\nIs there a way I can have a branch for each deployment where I can merge\nover any changes in either direction between any two branches? Would I\nneed some sort of central \"vanilla\" branch for this?\n"}]}