Jens Lehmann <Jens.Lehmann@xxxxxx> writes: > The "Submodules" section of the "git mv" documentation mentions what will > happen when a submodule with a gitfile gets moved with newer git. But it > doesn't talk about what happens when the user changes between commits > before and after the move, which does not update the work tree like using > the mv command did the first time. > > Explain what happens and what the user has to do manually to fix that. > Also document this in a new test. > > Reported-by: George Papanikolaou <g3orge.app@xxxxxxxxx> > Signed-off-by: Jens Lehmann <Jens.Lehmann@xxxxxx> > --- > > Am 09.12.2013 18:49, schrieb Jens Lehmann: >> Am 09.12.2013 11:59, schrieb George Papanikolaou: >>> Also after mv you need to run 'submodule update' and I think this should be >>> documented somewhere. >> >> You're right, this should be mentioned in the mv man page. I'll >> prepare a patch for that. > > Does this new paragraph make it clearer? Don't we have bugs section that we can use to list the known limitations like this? > Documentation/git-mv.txt | 10 ++++++++++ > t/t7001-mv.sh | 21 +++++++++++++++++++++ It also may make sense to express the test as "this is what we would like to see happen eventually" in the form of test_expect_failure; it is not a big deal though. > 2 files changed, 31 insertions(+) > > diff --git a/Documentation/git-mv.txt b/Documentation/git-mv.txt > index b1f7988..c9e8568 100644 > --- a/Documentation/git-mv.txt > +++ b/Documentation/git-mv.txt > @@ -52,6 +52,16 @@ core.worktree setting to make the submodule work in the new location. > It also will attempt to update the submodule.<name>.path setting in > the linkgit:gitmodules[5] file and stage that file (unless -n is used). > > +Please note that each time a superproject update moves a populated > +submodule (e.g. when switching between commits before and after the > +move) a stale submodule checkout will remain in the old location > +and an empty directory will appear in the new location. To populate > +the submodule again in the new location the user will have to run > +"git submodule update" afterwards. Removing the old directory is > +only safe when it uses a gitfile, as otherwise the history of the > +submodule will be deleted too. Both steps will be obsolete when > +recursive submodule update has been implemented. > + > GIT > --- > Part of the linkgit:git[1] suite > diff --git a/t/t7001-mv.sh b/t/t7001-mv.sh > index 3bfdfed..e3c8c2c 100755 > --- a/t/t7001-mv.sh > +++ b/t/t7001-mv.sh > @@ -442,4 +442,25 @@ test_expect_success 'mv --dry-run does not touch the submodule or .gitmodules' ' > git diff-files --quiet -- sub .gitmodules > ' > > +test_expect_success 'checking out a commit before submodule moved needs manual updates' ' > + git mv sub sub2 && > + git commit -m "moved sub to sub2" && > + git checkout -q HEAD^ 2>actual && > + echo "warning: unable to rmdir sub2: Directory not empty" >expected && > + test_i18ncmp expected actual && > + git status -s sub2 >actual && > + echo "?? sub2/" >expected && > + test_cmp expected actual && > + ! test -f sub/.git && > + test -f sub2/.git && > + git submodule update && > + test -f sub/.git && > + rm -rf sub2 && > + git diff-index --exit-code HEAD && > + git update-index --refresh && > + git diff-files --quiet -- sub .gitmodules && > + git status -s sub2 >actual && > + ! test -s actual > +' > + > test_done -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html