On Thu, Apr 19 2018, Junio C. Hamano wrote:
> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
>
>> We have a -s ours, but not a -s theirs. This is a WIP patch to implement
>> that. It works, but I haven't dealt with this part of the internal API
>> before, comments most welcome.
>>
>> The purpose of this is that I'm working with a rollout tool that is
>> capable of doing hotfixes on top of old commits on "master".
>>
>> It does this by cherry-picking a commit from origin/master, and then
>> merges it with origin/master & pushes it back, before finally reset
>> --hard to the cherry-pick & rolling out.
>>
>> The reason it's doing this is to maintain the guarantee that all rolled
>> out commits are reachable from "master", and to handle the more general
>> case where original work is made during a hotfix, we don't want to then
>> do a subsequent "normal" rollout and miss the fix.
>
> 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]
>
> Obviously you can do this the other way around if you had "-s
> theirs", i.e. instead of the last two lines from the above sequence,
> you could do
>
> $ git merge -s nth -X 2 origin/master
> $ git push origin HEAD:master
> $ git reset --hard HEAD@{1}
>
> but it is not all that interesting (at least to me) either way, as a
> larger issue with the above I'd imagine people would see is that
> even temporarily you would expose "master" material in that working
> tree you usually have "prod" checkout. That would irritate those
> who consider that "push to deploy" aka "live site is actually a
> working tree" is sensible more than the lack of "-s theirs" I would
> think.
Yeah this -s theirs is redundant to just doing it the other way around
as you describe.
The reason I want it is to always do the hotfix merge the same way
whether I'm dealing with a case where there's original work in the
hotfix (rare) or the case where there's just stuff to "prod"
cherry-picked from "master" (common).
I.e. I have:
1. No original work on the hotfix. As determined by comparing the
patch-id output of @{u}.. and ..@{u} and seeing if the patch ids I
have cherry-picked are from commits that exist since there was last
a full rollout.
2. Original work during the hotfix on top of "prod", which we'll then
want in the next rollout (when it'll be synced with "master").
Only #1 should use `-s theirs -X 2`, but #2 will just use the normal
merge strategy, i.e. it's possible we'll conflict, but then we should
resolve the conflict and push the fix to "master" (or at least
explicitly decide not to keep it).
I think that supporting this use-case explicitly in git is better than
having some unintuitive workaround where I'll first need to check out
the other branch purely because git-merge has an artificial limitation
of the "ours" driver having no mode to pick the Nth commit.
