RE: Doing a dummy or empty merge

From: Richard Lee <richard@webdezign.co.uk>
Date: Mar 15, 2010, 18:21 UTC
Message-ID: <8440EA2C12E50645A68C4AA9887166513FC532@SERVER.webdezign.local>
In-Reply-To: <864okmeeyd.fsf@blue.stonehenge.com>

>>>>> "Junio" == Junio C Hamano <gitster@pobox.com> writes:

Show 7 quoted lines

>> 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?