>>>>> "Junio" == Junio C Hamano <gitster@xxxxxxxxx> 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? -- 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