From: Benjamin Schindler Date: Tue, 31 Jan 2017 07:46:09 GMT Subject: Re: gitconfig get out of sync with submodule entries on branch switch Message-ID: In-Reply-To: <20170130175118.GA35626@google.com> Hi Brandon I did try your suggestion, so basically: git checkout branch git submodule init git submodule update Unfortunately, I still have two entries in my git config this way. It seems that git submodule update only considers submodules listed in .gitmodules. The background of my question is this - we have a jenkins farm which needs to switch branches continuously in an automated fashion and this needs to work even in when submodules are around. I did however, just now, find a reliable way to switch a branch, keeping the gitconfig in sync: The basic workflow for switching a branch is: git submodule deinit . git checkout branch git submodule init git submodule update Because the .git folder of the submodules are not within the submodule directories, this is, while still quite heavy-handed, reasonably fast and robust. At least it is better than deleting the entire repository every time a branch switch is issued. Regards Benjamin Schindler On 30.01.2017 18:51, Brandon Williams wrote: > On 01/30, Benjamin Schindler 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' >> >> 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. >> >> However, what is not good is that the submodule b is still known in >> .git/config. 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? >> >> thanks a lot >> Benjamin Schindler >> >> P.s. I did not subscribe to the mailing list, please add me at least >> do CC. Thanks > submodules and checkout don't really play nicely with each other at the > moment. Stefan (cc'd) is currently working on a patch series to improve > the behavior of checkout with submodules. Currently, if you want to > ensure you have a good working state after a checkout you should run > `git submodule update` to update all of the submoules. As far as your > submodule still being listed in the config, that should be expected > given the scenario you described. > > If I'm understanding you correctly, A and B are both the same submodule > just renamed on a different branch. The moment you add a submoule to a > repository it is given a name which is fixed. Typically this is the > path from the root of the repository. The thing is, since you are able > to freely move a submodule, its path can change. To account for this > there is the .gitmodules file which allows you to do a lookup from > submodule name to the path at which it exists (or vice versa). The > submodules that are stored in .git/config are those which are > 'initialize' or rather the submodules in which you are interested in and > will be updated by `git submodule update`. So given your scenario you > should only have a single submodule in .git/config and the .gitmodules > file should have a single entry with a differing path for each branch. > > Hopefully this gives you a bit more information to work with. Since > Stefan has been working with this more recently than me he may have some > more input. >