[lmi] Merge vs. cherry-pick [Was: PATCH: Submodule changes]

[Greg Chicares]

I've gotten the "lmi-so" changes into master, and pushed. Let's discuss
how I did this, though, in light of these two discussions, so that next
time I'll use the optimal technique.

  [lmi-so branch: merge vs cherry-pick [Was: PATCH: Submodule changes]]
On 2020-10-10 12:27, Vadim Zeitlin wrote:
[...]
>  But in any case, right now you don't need to cherry-pick anything: you can
> just fast-forward to this branch, i.e.
> 
>       $ git merge --ff-only shangri-la/ci-linux
> 
> Please make sure to redo "git fetch shangri-la" first, however, as there
> has been another tiny update to this branch, so its tip has changed.
> 
>  And, of course, if you do make any other commits to master, fast
> forwarding won't work and in this case you would indeed need to
> 
>       $ git cherry-pick ..shangri-la/ci-linux

  [Re: [lmi] PATCH: Submodule changes]
On 2020-10-09 15:30, Vadim Zeitlin wrote:
> On Fri, 9 Oct 2020 15:12:03 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
[...]
> GC> $git cherry-pick ..xanadu/wx-submodules           
> 
>  As usual, I'd have preferred "git merge xanadu/wx-submodules" but if you
> prefer linear history, this works, of course. An alternative to cherry
> picking would be to create a local branch and then rebase it on master, but
> this basically boils down to the same thing.

After of course doing this:
  git fetch shangri-la/lmi-so
we're discussing several methods:

  (1) git merge --ff-only shangri-la/lmi-so

  (2) git checkout --track shangri-la/lmi-so
      git rebase origin/master
      git switch master
      git merge --ff-only lmi-so

  (3) git cherry-pick ..shangri-la/lmi-so

where AIUI (2) is your last sentence quoted above. What are the preference
rankings, though? I'm sure you prefer (1) to (3), but is your ranking
  1 > 2 = 3 , or
  1 = 2 > 3 ?
And, since I do still prefer linear history, is my ranking
  3 > 2 = 1 , or
  3 = 2 = 1 ?

Here's what I did today. First of all, I had a few unpushed commits of my own,
so I pushed them in order to start clean. Looking back, I guess that's exactly
what ideally I would not have done, and instead I would have reset to
origin/master, stashed my commits, merged the branch, and then popped the stash.
Anyway, continuing...

/opt/lmi/src/lmi[0]$git checkout --track shangri-la/lmi-so
M       third_party/wxpdfdoc
Branch 'lmi-so' set up to track remote branch 'lmi-so' from 'shangri-la'.
Switched to a new branch 'lmi-so'
cmp: /opt/lmi/free/src/lmi//third_party/wxpdfdoc: Is a directory

[That seemed to work, but the 'cmp' error makes me uneasy.]

/opt/lmi/src/lmi[0]$git status
On branch lmi-so
Your branch is up to date with 'shangri-la/lmi-so'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   third_party/wxpdfdoc (new commits)

[Oh, no..."(new commits)" again.]

/opt/lmi/src/lmi[0]$git rebase origin/master 
First, rewinding head to replay your work on top of it...
cmp: /opt/lmi/free/src/lmi//third_party/wxpdfdoc: Is a directory
Applying: Fix using of LMI_SO macros for functions
Applying: Fix the SO attribute for the class forward delaration
Applying: Don't use disable-auto-import linker flag for the native Linux build
Applying: Enable lmi building with SO attributes for the native CI build

/opt/lmi/src/lmi[0]$git switch master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.

/opt/lmi/src/lmi[0]$git merge --ff-only lmi-so
Updating a8cb8e8d..0f314d35
Fast-forward

[Those last few steps seemed to work.]

Are those steps, which are (2) above, ideal from your POV?
 - ideal, because they preserve each commit message (but
     doesn't the cherry-pick technique do that as well?); or
 - not ideal, because they change the SHA1s?
Either way, if you rebase or I do, the SHA1s change; but do
you prefer to rebase shangri-la, because then the altered
SHA1s are "yours" in some sense, rather than have me rebase
my tracking branch, because then the SHA1s are "mine"?

Anyway, I wanted to get this done this morning before turning
to other things, and the messages above:
  cmp: /opt/lmi/free/src/lmi//third_party/wxpdfdoc: Is a directory
  modified:   third_party/wxpdfdoc (new commits)
scared me off using method (2), so I used (3) instead:

/opt/lmi/src/lmi[0]$git reset --hard origin/master 
HEAD is now at a8cb8e8d Transume $LD_LIBRARY_PATH and $WINEPATH in unison

/opt/lmi/src/lmi[0]$git cherry-pick ..shangri-la/lmi-so   
Auto-merging product_data.hpp
[master c1198b8a] Fix using of LMI_SO macros for functions
 Author: Ilya Sinitsyn <isinitsyn@tt-solutions.com>
 Date: Thu Oct 8 04:17:57 2020 +0700
 42 files changed, 137 insertions(+), 137 deletions(-)
[master 000b7e6f] Fix the SO attribute for the class forward delaration
 Author: Ilya Sinitsyn <isinitsyn@tt-solutions.com>
 Date: Thu Oct 8 04:51:49 2020 +0700
 1 file changed, 1 insertion(+), 1 deletion(-)
Auto-merging workhorse.make
[master 94ec0fa0] Don't use disable-auto-import linker flag for the native 
Linux build
 Author: Ilya Sinitsyn <isinitsyn@tt-solutions.com>
 Date: Thu Oct 8 05:13:31 2020 +0700
 1 file changed, 3 insertions(+), 1 deletion(-)
Auto-merging .github/workflows/ci.yml
[master 4792ae82] Enable lmi building with SO attributes for the native CI build
 Author: Ilya Sinitsyn <isinitsyn@tt-solutions.com>
 Date: Mon Oct 12 08:52:51 2020 +0700
 1 file changed, 1 deletion(-)

and now `git status` is clean and third_party/wxpdfdoc doesn't
seem to have any weird problems, so this seemed like the best
I could do at the moment. Maybe you've already explained, and
I just haven't understood, but what drawback does this method
have from your POV? Is it just that now we have equivalent
commits, but with different SHA1s? Can you resolve that by
running some easy command (I can't guess what it would be)
that brings everything back into alignment? Or have I created
some irresolvable problem on your side?

BTW, the wxpdfdoc submodule looks good:

/opt/lmi/src/lmi[0]$git submodule status third_party/wxpdfdoc
 1839b231c5138edd40b752272631e2f1d5311456 third_party/wxpdfdoc 
(v0.9.8-13-g1839b23)

after method (3). Have you any idea why method (2) reintroduced the
  modified:   third_party/wxpdfdoc (new commits)
issue? Is it that I had earlier done something suboptimal
that infected Ilya's branch when it was rebased on my
origin/master, i.e. my
  03f3e19a Add '/autom4te.cache' to 'wxpdfdoc' submodule's '.gitignore'
without your subsequent
  b01ffaf8 Update wxpdfdoc submodule to contain the previous commit
correction?