Re: [BUG] submodule move badly handled by git-rebase

[ydirson@free.fr]

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
> 
>