* [BUG] submodule move badly handled by git-rebase
[not found] <702823257.805273759.1586276452976.JavaMail.root@zimbra39-e7>
@ 2020-04-07 16:34 ` ydirson
2020-04-07 20:49 ` Elijah Newren
0 siblings, 1 reply; 6+ messages in thread
From: ydirson @ 2020-04-07 16:34 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1885 bytes --]
Hello all,
When rebasing commits involving move of a submodule, git-rebase fails to
record in index the "add" part of the rename. This leaves the workdir
dirty and the rebase gets stopped.
fast-export of a testcase is attached. To reproduce, just
"git rebase -i", add a "break" before the move commit,
use this to introduce some noise, and watch.
Best regards,
--
Yann
(master)$ git rebase -i HEAD^^
hint: Waiting for your editor to close the file... Waiting for Emacs...
Stopped at b0e1b00... add submodule
(master|REBASE 2/3)$ echo >>README
(master|REBASE 2/3)$ git commit -a -m noise
[detached HEAD d67c886] noise
1 file changed, 1 insertion(+)
(master|REBASE 2/3)$ git rebase --continue
Adding as subdir/gitlab-oe~08e230f... move submodule instead
error: could not apply 08e230f... move submodule
Resolve all conflicts manually, mark them as resolved with
"git add/rm <conflicted_files>", then run "git rebase --continue".
You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase --abort".
Could not apply 08e230f... move submodule
(master|REBASE 3/3)$ git st
interactive rebase in progress; onto c21ef8e
Last commands done (3 commands done):
break
pick 08e230f move submodule
(see more in file .git/rebase-merge/done)
No commands remaining.
You are currently rebasing branch 'master' on 'c21ef8e'.
(fix conflicts and then run "git rebase --continue")
(use "git rebase --skip" to skip this patch)
(use "git rebase --abort" to check out the original branch)
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: .gitmodules
deleted: gitlab-oe
Unmerged paths:
(use "git restore --staged <file>..." to unstage)
(use "git add <file>..." to mark resolution)
added by them: subdir/gitlab-oe
(master|REBASE 3/3)$
[-- Attachment #2: submodule-move.fexp --]
[-- Type: application/octet-stream, Size: 1034 bytes --]
blob
mark :1
data 4
foo
reset refs/heads/master
commit refs/heads/master
mark :2
author Yann Dirson <yann@blade-group.com> 1586276255 +0200
committer Yann Dirson <yann@blade-group.com> 1586276255 +0200
data 8
initial
M 100644 :1 README
blob
mark :3
data 93
[submodule "gitlab-oe"]
path = gitlab-oe
url = https://github.com/BladeGroup/gitlab-oe.git
commit refs/heads/master
mark :4
author Yann Dirson <yann@blade-group.com> 1586276297 +0200
committer Yann Dirson <yann@blade-group.com> 1586276297 +0200
data 14
add submodule
from :2
M 100644 :3 .gitmodules
M 160000 dd943dc6c97664d409feaaff3647c242dbb300df gitlab-oe
blob
mark :5
data 100
[submodule "gitlab-oe"]
path = subdir/gitlab-oe
url = https://github.com/BladeGroup/gitlab-oe.git
commit refs/heads/master
mark :6
author Yann Dirson <yann@blade-group.com> 1586276328 +0200
committer Yann Dirson <yann@blade-group.com> 1586276328 +0200
data 15
move submodule
from :4
M 100644 :5 .gitmodules
D gitlab-oe
M 160000 dd943dc6c97664d409feaaff3647c242dbb300df subdir/gitlab-oe
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [BUG] submodule move badly handled by git-rebase
2020-04-07 16:34 ` [BUG] submodule move badly handled by git-rebase ydirson
@ 2020-04-07 20:49 ` Elijah Newren
2020-04-08 7:52 ` ydirson
0 siblings, 1 reply; 6+ messages in thread
From: Elijah Newren @ 2020-04-07 20:49 UTC (permalink / raw)
To: ydirson; +Cc: git
Hi Yann,
On Tue, Apr 7, 2020 at 9:36 AM <ydirson@free.fr> wrote:
>
> Hello all,
>
> When rebasing commits involving move of a submodule, git-rebase fails to
> record in index the "add" part of the rename. This leaves the workdir
> dirty and the rebase gets stopped.
>
> fast-export of a testcase is attached. To reproduce, just
> "git rebase -i", add a "break" before the move commit,
> use this to introduce some noise, and watch.
>
> Best regards,
> --
> Yann
>
>
> (master)$ git rebase -i HEAD^^
> hint: Waiting for your editor to close the file... Waiting for Emacs...
> Stopped at b0e1b00... add submodule
>
> (master|REBASE 2/3)$ echo >>README
>
> (master|REBASE 2/3)$ git commit -a -m noise
> [detached HEAD d67c886] noise
> 1 file changed, 1 insertion(+)
>
> (master|REBASE 2/3)$ git rebase --continue
> Adding as subdir/gitlab-oe~08e230f... move submodule instead
> error: could not apply 08e230f... move submodule
> Resolve all conflicts manually, mark them as resolved with
> "git add/rm <conflicted_files>", then run "git rebase --continue".
> You can instead skip this commit: run "git rebase --skip".
> To abort and get back to the state before "git rebase", run "git rebase --abort".
> Could not apply 08e230f... move submodule
>
> (master|REBASE 3/3)$ git st
> interactive rebase in progress; onto c21ef8e
> Last commands done (3 commands done):
> break
> pick 08e230f move submodule
> (see more in file .git/rebase-merge/done)
> No commands remaining.
> You are currently rebasing branch 'master' on 'c21ef8e'.
> (fix conflicts and then run "git rebase --continue")
> (use "git rebase --skip" to skip this patch)
> (use "git rebase --abort" to check out the original branch)
>
> Changes to be committed:
> (use "git restore --staged <file>..." to unstage)
> modified: .gitmodules
> deleted: gitlab-oe
>
> Unmerged paths:
> (use "git restore --staged <file>..." to unstage)
> (use "git add <file>..." to mark resolution)
> added by them: subdir/gitlab-oe
>
> (master|REBASE 3/3)$
I couldn't figure out how to duplicate. Maybe I did something wrong,
but it was:
# download your fast-export stream
git init temp
cd temp
cat ~/Downloads/submodule-move.fexp | git fast-import --quiet
git checkout master
git rebase -i HEAD^^
# Insert a line with just 'b' between the two pick lines; save and
exit and when it breaks:
echo >>README
git commit -a -m noise
git rebase --continue
After the rebase --continue, the rebase completes just fine applying
the patch with the submodule move. git range-diff master@{1}... will
show that I inserted a new commit in the middle. git log --raw looks
good, showing all four commits including the moved submodule at the
end.
What git version did you use? Do you need special settings (what's in
your ~/.gitconfig and your .git/config)?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [BUG] submodule move badly handled by git-rebase
2020-04-07 20:49 ` Elijah Newren
@ 2020-04-08 7:52 ` ydirson
2020-04-08 16:21 ` Elijah Newren
2020-04-08 16:23 ` ydirson
0 siblings, 2 replies; 6+ messages in thread
From: ydirson @ 2020-04-08 7:52 UTC (permalink / raw)
To: Elijah Newren; +Cc: git
Hi Elijah,
> Hi Yann,
>
> On Tue, Apr 7, 2020 at 9:36 AM <ydirson@free.fr> wrote:
> >
> > Hello all,
> >
> > When rebasing commits involving move of a submodule, git-rebase
> > fails to
> > record in index the "add" part of the rename. This leaves the
> > workdir
> > dirty and the rebase gets stopped.
> >
> > fast-export of a testcase is attached. To reproduce, just
> > "git rebase -i", add a "break" before the move commit,
> > use this to introduce some noise, and watch.
> >
> > Best regards,
> > --
> > Yann
> >
> >
> > (master)$ git rebase -i HEAD^^
> > hint: Waiting for your editor to close the file... Waiting for
> > Emacs...
> > Stopped at b0e1b00... add submodule
> >
> > (master|REBASE 2/3)$ echo >>README
> >
> > (master|REBASE 2/3)$ git commit -a -m noise
> > [detached HEAD d67c886] noise
> > 1 file changed, 1 insertion(+)
> >
> > (master|REBASE 2/3)$ git rebase --continue
> > Adding as subdir/gitlab-oe~08e230f... move submodule instead
> > error: could not apply 08e230f... move submodule
> > Resolve all conflicts manually, mark them as resolved with
> > "git add/rm <conflicted_files>", then run "git rebase --continue".
> > You can instead skip this commit: run "git rebase --skip".
> > To abort and get back to the state before "git rebase", run "git
> > rebase --abort".
> > Could not apply 08e230f... move submodule
> >
> > (master|REBASE 3/3)$ git st
> > interactive rebase in progress; onto c21ef8e
> > Last commands done (3 commands done):
> > break
> > pick 08e230f move submodule
> > (see more in file .git/rebase-merge/done)
> > No commands remaining.
> > You are currently rebasing branch 'master' on 'c21ef8e'.
> > (fix conflicts and then run "git rebase --continue")
> > (use "git rebase --skip" to skip this patch)
> > (use "git rebase --abort" to check out the original branch)
> >
> > Changes to be committed:
> > (use "git restore --staged <file>..." to unstage)
> > modified: .gitmodules
> > deleted: gitlab-oe
> >
> > Unmerged paths:
> > (use "git restore --staged <file>..." to unstage)
> > (use "git add <file>..." to mark resolution)
> > added by them: subdir/gitlab-oe
> >
> > (master|REBASE 3/3)$
>
> I couldn't figure out how to duplicate. Maybe I did something wrong,
> but it was:
> # download your fast-export stream
> git init temp
> cd temp
> cat ~/Downloads/submodule-move.fexp | git fast-import --quiet
> git checkout master
> git rebase -i HEAD^^
> # Insert a line with just 'b' between the two pick lines; save
> and
> exit and when it breaks:
> echo >>README
> git commit -a -m noise
> git rebase --continue
>
> After the rebase --continue, the rebase completes just fine applying
> the patch with the submodule move. git range-diff master@{1}... will
> show that I inserted a new commit in the middle. git log --raw looks
> good, showing all four commits including the moved submodule at the
> end.
You're right, I missed crucial point: no problem appears unless the submodule
is initialized. After checking out the master branch (and possibly issuing
"git reset --hard" to make sure everything is clean), it is necessary to
run "git submodule update --init".
> What git version did you use? Do you need special settings (what's
> in
> your ~/.gitconfig and your .git/config)?
This is 2.26.0, but like my other report I had it with 2.25.1 already.
Just tested with an clear config (HOME and GIT_CONFIG_NOSYSTEM set) and
the problem triggers as well.
Best regards,
--
Yann
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [BUG] submodule move badly handled by git-rebase
2020-04-08 7:52 ` ydirson
@ 2020-04-08 16:21 ` Elijah Newren
2020-04-08 16:23 ` ydirson
1 sibling, 0 replies; 6+ messages in thread
From: Elijah Newren @ 2020-04-08 16:21 UTC (permalink / raw)
To: ydirson; +Cc: git
Hi Yann,
On Wed, Apr 8, 2020 at 12:52 AM <ydirson@free.fr> wrote:
>
> Hi Elijah,
>
> > Hi Yann,
> >
> > On Tue, Apr 7, 2020 at 9:36 AM <ydirson@free.fr> wrote:
> > >
> > > Hello all,
> > >
> > > When rebasing commits involving move of a submodule, git-rebase
> > > fails to
> > > record in index the "add" part of the rename. This leaves the
> > > workdir
> > > dirty and the rebase gets stopped.
> > >
> > > fast-export of a testcase is attached. To reproduce, just
> > > "git rebase -i", add a "break" before the move commit,
> > > use this to introduce some noise, and watch.
> > >
> > > Best regards,
> > > --
> > > Yann
> > >
> > >
> > > (master)$ git rebase -i HEAD^^
> > > hint: Waiting for your editor to close the file... Waiting for
> > > Emacs...
> > > Stopped at b0e1b00... add submodule
> > >
> > > (master|REBASE 2/3)$ echo >>README
> > >
> > > (master|REBASE 2/3)$ git commit -a -m noise
> > > [detached HEAD d67c886] noise
> > > 1 file changed, 1 insertion(+)
> > >
> > > (master|REBASE 2/3)$ git rebase --continue
> > > Adding as subdir/gitlab-oe~08e230f... move submodule instead
> > > error: could not apply 08e230f... move submodule
> > > Resolve all conflicts manually, mark them as resolved with
> > > "git add/rm <conflicted_files>", then run "git rebase --continue".
> > > You can instead skip this commit: run "git rebase --skip".
> > > To abort and get back to the state before "git rebase", run "git
> > > rebase --abort".
> > > Could not apply 08e230f... move submodule
> > >
> > > (master|REBASE 3/3)$ git st
> > > interactive rebase in progress; onto c21ef8e
> > > Last commands done (3 commands done):
> > > break
> > > pick 08e230f move submodule
> > > (see more in file .git/rebase-merge/done)
> > > No commands remaining.
> > > You are currently rebasing branch 'master' on 'c21ef8e'.
> > > (fix conflicts and then run "git rebase --continue")
> > > (use "git rebase --skip" to skip this patch)
> > > (use "git rebase --abort" to check out the original branch)
> > >
> > > Changes to be committed:
> > > (use "git restore --staged <file>..." to unstage)
> > > modified: .gitmodules
> > > deleted: gitlab-oe
> > >
> > > Unmerged paths:
> > > (use "git restore --staged <file>..." to unstage)
> > > (use "git add <file>..." to mark resolution)
> > > added by them: subdir/gitlab-oe
> > >
> > > (master|REBASE 3/3)$
> >
> > I couldn't figure out how to duplicate. Maybe I did something wrong,
> > but it was:
> > # download your fast-export stream
> > git init temp
> > cd temp
> > cat ~/Downloads/submodule-move.fexp | git fast-import --quiet
> > git checkout master
> > git rebase -i HEAD^^
> > # Insert a line with just 'b' between the two pick lines; save
> > and
> > exit and when it breaks:
> > echo >>README
> > git commit -a -m noise
> > git rebase --continue
> >
> > After the rebase --continue, the rebase completes just fine applying
> > the patch with the submodule move. git range-diff master@{1}... will
> > show that I inserted a new commit in the middle. git log --raw looks
> > good, showing all four commits including the moved submodule at the
> > end.
>
> You're right, I missed crucial point: no problem appears unless the submodule
> is initialized. After checking out the master branch (and possibly issuing
> "git reset --hard" to make sure everything is clean), it is necessary to
> run "git submodule update --init".
>
>
> > What git version did you use? Do you need special settings (what's
> > in
> > your ~/.gitconfig and your .git/config)?
>
> This is 2.26.0, but like my other report I had it with 2.25.1 already.
> Just tested with an clear config (HOME and GIT_CONFIG_NOSYSTEM set) and
> the problem triggers as well.
Ah, gotcha. With the "git submodule update --init", I can duplicate
with 2.26.0 and 2.24.1 and I probably could with any other git version
going back to when submodules were introduced.
I decided to also test with the "ort" merge strategy[1] that I haven't
worked on in over a month. It fixes this testcase. So this is yet
another example of it having better correctness than merge-recursive.
Thanks for the report.
Elijah
[1] https://github.com/newren/git/tree/git-merge-2020-demo
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [BUG] submodule move badly handled by git-rebase
2020-04-08 7:52 ` ydirson
2020-04-08 16:21 ` Elijah Newren
@ 2020-04-08 16:23 ` ydirson
2020-04-08 16:33 ` Elijah Newren
1 sibling, 1 reply; 6+ messages in thread
From: ydirson @ 2020-04-08 16:23 UTC (permalink / raw)
To: Elijah Newren; +Cc: git
This may be related to another funky behaviour I just noticed, linked
to moving submodules around:
- when initially created, the $TOP/orig-name submodule's git-dir gets created in
$TOP/.git/modules/orig-name, with $TOP/.git/modules/orig-name/config
containing a core.worktree value pointing to $TOP/orig-name
- when moving the submodule, only the submodule worktree is moved, the git-dir
being the same $TOP/.git/modules/orig-name, where the core.worktree still
points to the old location
Other unwanted behaviour include "git clean" reporting (and possibly cleaning)
files from the wrong work tree - it took me head-scratching to understand why
"git clean -fdx" was ignoring all the cruft I had in this worktree...
Why is it that we need a core.worktree setting at all in there ? Removing it
allows "git clean" to do what's expected of it. OTOH it does not make the
original problem go away...
----- Mail original -----
> De: ydirson@free.fr
> À: "Elijah Newren" <newren@gmail.com>
> Cc: "git" <git@vger.kernel.org>
> Envoyé: Mercredi 8 Avril 2020 09:52:59
> Objet: Re: [BUG] submodule move badly handled by git-rebase
>
> Hi Elijah,
>
> > Hi Yann,
> >
> > On Tue, Apr 7, 2020 at 9:36 AM <ydirson@free.fr> wrote:
> > >
> > > Hello all,
> > >
> > > When rebasing commits involving move of a submodule, git-rebase
> > > fails to
> > > record in index the "add" part of the rename. This leaves the
> > > workdir
> > > dirty and the rebase gets stopped.
> > >
> > > fast-export of a testcase is attached. To reproduce, just
> > > "git rebase -i", add a "break" before the move commit,
> > > use this to introduce some noise, and watch.
> > >
> > > Best regards,
> > > --
> > > Yann
> > >
> > >
> > > (master)$ git rebase -i HEAD^^
> > > hint: Waiting for your editor to close the file... Waiting for
> > > Emacs...
> > > Stopped at b0e1b00... add submodule
> > >
> > > (master|REBASE 2/3)$ echo >>README
> > >
> > > (master|REBASE 2/3)$ git commit -a -m noise
> > > [detached HEAD d67c886] noise
> > > 1 file changed, 1 insertion(+)
> > >
> > > (master|REBASE 2/3)$ git rebase --continue
> > > Adding as subdir/gitlab-oe~08e230f... move submodule instead
> > > error: could not apply 08e230f... move submodule
> > > Resolve all conflicts manually, mark them as resolved with
> > > "git add/rm <conflicted_files>", then run "git rebase
> > > --continue".
> > > You can instead skip this commit: run "git rebase --skip".
> > > To abort and get back to the state before "git rebase", run "git
> > > rebase --abort".
> > > Could not apply 08e230f... move submodule
> > >
> > > (master|REBASE 3/3)$ git st
> > > interactive rebase in progress; onto c21ef8e
> > > Last commands done (3 commands done):
> > > break
> > > pick 08e230f move submodule
> > > (see more in file .git/rebase-merge/done)
> > > No commands remaining.
> > > You are currently rebasing branch 'master' on 'c21ef8e'.
> > > (fix conflicts and then run "git rebase --continue")
> > > (use "git rebase --skip" to skip this patch)
> > > (use "git rebase --abort" to check out the original branch)
> > >
> > > Changes to be committed:
> > > (use "git restore --staged <file>..." to unstage)
> > > modified: .gitmodules
> > > deleted: gitlab-oe
> > >
> > > Unmerged paths:
> > > (use "git restore --staged <file>..." to unstage)
> > > (use "git add <file>..." to mark resolution)
> > > added by them: subdir/gitlab-oe
> > >
> > > (master|REBASE 3/3)$
> >
> > I couldn't figure out how to duplicate. Maybe I did something
> > wrong,
> > but it was:
> > # download your fast-export stream
> > git init temp
> > cd temp
> > cat ~/Downloads/submodule-move.fexp | git fast-import --quiet
> > git checkout master
> > git rebase -i HEAD^^
> > # Insert a line with just 'b' between the two pick lines; save
> > and
> > exit and when it breaks:
> > echo >>README
> > git commit -a -m noise
> > git rebase --continue
> >
> > After the rebase --continue, the rebase completes just fine
> > applying
> > the patch with the submodule move. git range-diff master@{1}...
> > will
> > show that I inserted a new commit in the middle. git log --raw
> > looks
> > good, showing all four commits including the moved submodule at the
> > end.
>
> You're right, I missed crucial point: no problem appears unless the
> submodule
> is initialized. After checking out the master branch (and possibly
> issuing
> "git reset --hard" to make sure everything is clean), it is necessary
> to
> run "git submodule update --init".
>
>
> > What git version did you use? Do you need special settings (what's
> > in
> > your ~/.gitconfig and your .git/config)?
>
> This is 2.26.0, but like my other report I had it with 2.25.1
> already.
> Just tested with an clear config (HOME and GIT_CONFIG_NOSYSTEM set)
> and
> the problem triggers as well.
>
> Best regards,
> --
> Yann
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [BUG] submodule move badly handled by git-rebase
2020-04-08 16:23 ` ydirson
@ 2020-04-08 16:33 ` Elijah Newren
0 siblings, 0 replies; 6+ messages in thread
From: Elijah Newren @ 2020-04-08 16:33 UTC (permalink / raw)
To: ydirson; +Cc: git
On Wed, Apr 8, 2020 at 9:23 AM <ydirson@free.fr> wrote:
>
> This may be related to another funky behaviour I just noticed, linked
> to moving submodules around:
>
> - when initially created, the $TOP/orig-name submodule's git-dir gets created in
> $TOP/.git/modules/orig-name, with $TOP/.git/modules/orig-name/config
> containing a core.worktree value pointing to $TOP/orig-name
> - when moving the submodule, only the submodule worktree is moved, the git-dir
> being the same $TOP/.git/modules/orig-name, where the core.worktree still
> points to the old location
>
> Other unwanted behaviour include "git clean" reporting (and possibly cleaning)
> files from the wrong work tree - it took me head-scratching to understand why
> "git clean -fdx" was ignoring all the cruft I had in this worktree...
>
> Why is it that we need a core.worktree setting at all in there ? Removing it
> allows "git clean" to do what's expected of it. OTOH it does not make the
> original problem go away...
Not knowing much about submodules, I'm going to leave submodule issues
that don't touch on the merge-machinery or rebase code to someone else
to handle. (I'd probably do the same with the merge-machinery and
rebase side if I wasn't worried about 2.26.0 regressions in rebase and
if I hadn't find a clever way to re-use checkout code to avoid lots of
submodule issues while also deleting code in the "ort" merge
strategy).
Hopefully someone else on the list who knows more about submodules can
chime in on the worktree related bits.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-04-08 16:34 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <702823257.805273759.1586276452976.JavaMail.root@zimbra39-e7>
2020-04-07 16:34 ` [BUG] submodule move badly handled by git-rebase ydirson
2020-04-07 20:49 ` Elijah Newren
2020-04-08 7:52 ` ydirson
2020-04-08 16:21 ` Elijah Newren
2020-04-08 16:23 ` ydirson
2020-04-08 16:33 ` Elijah Newren
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).