Æ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.
