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
