Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > On Thu, Apr 19 2018, Junio C. Hamano wrote: > >> This question has nothing to do with your "-s theirs" but let me see >> if I got the above correctly. Suppose you have a deployed branch >> (say, "prod"), all developments happen on "master" elsewhere that >> can be seen as "origin/master", so you may have a few fixes that is >> not yet in "prod" you would want to cherry-pick from origin/master. >> >> $ git checkout prod >> $ git cherry-pick origin/master~2 >> $ git cherry-pick origin/master >> >> Let's say that "master" had a fix at HEAD~2, HEAD~1 is a feature >> enhancement that is not yet ready for "prod", and HEAD is another >> fix. Up to this point you successfully back-ported the fixes to >> "prod". >> >> Then you do merge the tip into "master", i.e. >> >> $ git checkout origin/master && git merge -s ours prod >> $ git push origin HEAD:master >> $ git checkout prod >> >> to make sure that the "master" at the source of truth knows that >> it already has what our "prod" with these two cherry-picks have. >> >> Is that what is going on here? >> >> I am just wondering what would and should happen to the non-fix >> commit in the middle in the above example. Perhaps your workflow >> automatically does the right thing to it, perhaps not. >> >> >> [Footnote] >> ... > Yeah this -s theirs is redundant to just doing it the other way around > as you describe. > ... Heh, you responded to a much less relevant footnote without addressing the main part of the message which was a more interesting question to me ;-)
