Re: gitconfig get out of sync with submodule entries on branch switch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 06.02.2017 11:35, Stefan Beller wrote:
Answering the original email, as I feel we're going down the wrong rabbit
hole in the existing thread.

On Mon, Jan 30, 2017 at 8:21 AM, Benjamin Schindler
<beschindler@xxxxxxxxx> wrote:
Hi

Consider the following usecase: I have the master branch where I have a
submodule A. I create a branch where I rename the submodule to be in the
directory B. After doing all of this, everything looks good.
Now, I switch back to master. The first oddity is, that it fails to remove
the folder B because there are still files in there:

bschindler@metis ~/Projects/submodule_test (testbranch) $ git checkout
master
warning: unable to rmdir other_submodule: Directory not empty
Switched to branch 'master'

checkout currently doesn't support submodules, so it should neither
try to delete B nor try to repopulate A when switching back to master.
checkout ought to not even touch the existing submodule B.

Well, it tried to remove the folder (the rmdir warning) but it failed so in some sense you are right. Is there a technical reason for this default though? Here, I frequently have to point out to people that they need to initialize/update the submodule on e.g. clone.



Git submodule deinit on B fails because the submodule is not known to git
anymore (after all, the folder B exists only in the other branch). I can
easily just remove the folder B from disk and initialize the submodule A
again, so all seems good.

by initializing you mean populating(?), i.e.

    git submodule update

would work without the --init flag or preceding "git submodule init A".
That ought to not redownload A, but just put files back in the working tree
from the submodule git directory inside the superprojects git dir.


However, what is not good is that the submodule b is still known in
.git/config.

Oh, I see. You did not just rename the path, but also the name
in the .gitmodules?

I wasn't even aware that the submodule name was something different from the path because the name is by default set to be the path to it. So yes, I didn't just relocate it, it had a different name.


This is in particular a problem for us, because I know a number
of tools which use git config to retrieve the submodule list. Is it
therefore a bug that upon branch switch, the submodule gets deregistered,
but its entry in .git/config remains?

The config remains as it indicates that you express(ed) interest in
submodule A, such that when switching branches

  master->renamedToB->master

then we'd still care about A. As for the tools, I'd rather see them use

    git submodule status/summary

instead of directly looking at the config, because the config may
change in the future.

That was my feeling but its good to know to have more solid reasons why that would be.

Cheers
Benjamin



thanks a lot
Benjamin Schindler

P.s. I did not subscribe to the mailing list, please add me at least do CC.
Thanks



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]