Hi, On Mon, Apr 12, 2021 at 7:59 AM Tamas Peregi <tamas.peregi@xxxxxxxxxxxx> wrote: > > Hi all, > > I ran into something that seems like a bug to me. I'm fairly new to > git, especially git submodules, so it's possible this is expected > behaviour, but if it is, please explain where I went wrong. > > Thanks in advance: Tamás > > What did you do before the bug happened? (Steps to reproduce your issue) > ======================================================================== > > - I modified a file on one branch > - Then switched to another > - Moved a submodule to another directory > - Tried to cherry-pick my modification from the other branch > > This script can be used to reproduce my steps (any submodule works, I > chose gsl-lite because I like it): > git init > > echo hello > hello.txt > git add hello.txt > git commit -m "Add hello.txt" > > git submodule add https://github.com/gsl-lite/gsl-lite/ vendor/gsl > git commit -a -m "Add submodule" > > git branch world > git branch move > > git checkout world > echo world >> hello.txt > git commit -a -m "Expand hello.txt" > > git checkout move > mkdir thirdparty > git mv vendor/gsl thirdparty/gsl > git commit -a -m "Move submodule" > > git cherry-pick world > > > What did you expect to happen? (Expected behavior) > ================================================== > > I expected the cherry-pick to happen without conflicts. > > > What happened instead? (Actual behavior) > ======================================== > I ran into a conflict during the cherry-pick: > Adding as thirdparty/gsl~HEAD instead > error: could not apply 516d94f... Expand hello.txt > hint: after resolving the conflicts, mark the corrected paths > hint: with 'git add <paths>' or 'git rm <paths>' > hint: and commit the result with 'git commit' > > > What's different between what you expected and what actually happened? > ====================================================================== > > As hello.txt has nothing to do with the submodule, I assumed the > cherry-pick would go through smoothly. > > > Anything else you want to add: > ============================== > > - "git add thirdparty/gsl && git cherry-pick --continue" resolves the > issue as expected. > - If I change which commit in the submodule the superproject points > to, the problem disappears, but I don't necessarily want to do that. > - I'm using "Git for Windows", but the issue was reproduced by my > Mac-based colleagues too with the exact same results. > > [System Info] > git version: > git version 2.31.1.windows.1 > cpu: x86_64 > built from commit: c5f0be26a7e3846e3b6268d1c6c4800d838c6bbb > sizeof-long: 4 > sizeof-size_t: 8 > shell-path: /bin/sh > feature: fsmonitor--daemon > uname: Windows 10.0 19042 > compiler info: gnuc: 10.2 > libc info: no libc information available > $SHELL (typically, interactive shell): C:\Program Files\Git\usr\bin\bash.exe Thanks for the report. We can change the final command to git cherry-pick --strategy recursive world to be more explicit, though that doesn't change things and still triggers the bug. However, if we change the above to git cherry-pick --strategy ort world then that fixes the bug, including even in git-2.31.1. The version of the 'ort' merge backend in 2.31.1 isn't ready for general usage (it can't handle file renormalization, or subtree merges, or sparse-checkouts with conflicts in files outside of the requested sparsity paths, and also has a platform specific bug where it'll die on corner case rename/rename conflicts due to assumptions about libc qsort() stability), but the version in 2.32 will be. And 'ort' is going to replace 'recursive' once the project is comfortable enough with the new backend. All this is to say that the fix is on the way, even if it doesn't help you quite yet.
