On Thu, Apr 19 2018, Junio C. Hamano wrote:
I suppose this is more in reply to
xmqqpo2ud9ih.fsf@xxxxxxxxxxxxxxxxxxxxxxxxx. I was trying to answer all
your questions in my 87r2nbeh1r.fsf@xxxxxxxxxxxxxxxxxxx, but I think it
wasn't clear, hopefully this inline clears things up.
> Æ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?
Yes, the idea is that all commits that are rolled out are reachable from
"master". In my case there's no "prod" branch.
Instead we just have a tag on an older version of "master", and we're
applying a hotfix (usually one cherry-picked commit) to that tag.
We then push a merge of that origin/master back to origin/master so that:
1. The commit is reachable from "master" as discussed. I.e. a "git
clone" with the default tag follow logic will bring in that tag & I
just need to bring in master to bring in every thing ever rolled
out, not bring in every tag.
2. Because the working tree is now in a state where we're at that
hotfix tag, and we want to fast-forward to origin/master on the next
"real" rollout.
We could just 'reset --hard' in those cases, but it's easier to
always be able to do a "git pull" (except when initiating a hotfix).
> 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.
If there's a non-fix commit that contains any original work in the
hotfix I won't be able to use this ~-s theirs" strategy, and I detect
such case swith the patch-id method discussed in
87r2nbeh1r.fsf@xxxxxxxxxxxxxxxxxxx. Then we'll need to use the default
merge logic.
That's actually what we're doing now, but after running into several
bugs with merges gone wrong I'm hoping to fix it, and without bending
over backwards to use -s ours by doing the merge the other way around.
