AliSoftware
commented
2 years ago
trunk->Allow WordPress.com site address login for Jetpack app-> 246294drelease/0.11.1->Allow wpcom site address login for Jetpack app-> 64af999Actually, I am not even sure why that happened in the first place, that's why I was a bit confused while doing this WPAndroid release PR earlier. Wdyt? 🤔
The fact that the commits have different hash is not surprising, since this is a cherry-pick. So totally typical for them to be different commits in the eyes of git, with a different sha1, as long as they end up with the same content
The fact that the commits differ a bit is not really that surprising after all, because:
- 64af999 is from the
release/0.11.1branch, which was cut from0.11.0tag to ensure we only included that fix in the client app's code-frozen branch, and ensure we did not include any new commit which landed intrunkpost-code-freeze and are not supposed to be included in 19.3; - while 246294d is from the
trunkbranch, and thus also included more commits (which landed in login lib'strunkpost-code-freeze) — especially including a229c42dc36badcc39f7be3d3ad5231bb031eee9 which, despite being unrelated to the fix which landed there, still changed the sameLoginSiteAddressFragment.javafile that the fix changed.
Which is, imho, why GitHub was disturbed and considered those cherry-picks to not be fully equal (because the file changed in trunk in-between so it couldn't be sure this unrelated change didn't have a side effect from the other change from a229c42dc36badcc39f7be3d3ad5231bb031eee9 in trunk?).
That's also the whole reason why we cut a release/0.11.1 from 0.11.0 instead of landing the fix directly in trunk in the first place — because we didn't want to include more recent (post-code-freeze) commits from trunk in the 19.3-rc-2 as those changed the same file (albeit for a completely unrelated thing, but GitHub would have a hard time knowing that for sure)
Now that
0.11.1, which was cut from previous tag0.11.0to land a fix specific to the JPAndroid code-frozen beta (see https://github.com/wordpress-mobile/WordPress-Android/pull/16025 then https://github.com/wordpress-mobile/WordPress-Android/pull/16034)), has landed, we need to merge thatrelease/0.11.1back to `trunk to reconcile the branches.PS: I've also published the GitHub Release for 0.11.1
Empty Diff & Cherry-Pick
Note that since #82 (which landed on
release/0.11.1) was already a cherry-pick of #80 (which landed ontrunk), that's why the diff is empty. Still, in order to make it clear in the git history that thisrelease/0.11.1finally landed, it is still a good idea/practice to merge the release branch back totrunkanyway, despite the empty diff here, to keep the git graph consistent.EDIT: Strangely, it seems that GitHub still shows a non-empty diff on this PR 🤔 Despite what I explained above, and also the fact that the diff is indeed empty if I do the merge of
release/0.11.1intotrunklocally…I think (?) that this might be because in practice the change from #82 and #80, despite being the same changes, don't end up on the same line number in the end (because unrelated code was added above those lines in the other PRs which landed to
trunkin-between, shifting the line number), them being on line 414 inrelease/0.11.1but on line 474 intrunk… so maybe that's why GitHub ends up showing a non-empty diff in its UI? But if you compare those 2 links above manually you can see that they are the same changes anyway 🤷