On Mon, Jan 30, 2017 at 11:46 PM, Benjamin Schindler
<beschindler@xxxxxxxxx> wrote:
> Hi Brandon
>
> I did try your suggestion, so basically:
>
> git checkout branch
> git submodule init
> git submodule update
Eventually this becomes
git submudule update --init
git checkout --recurse-submodules $branch
>
> Unfortunately, I still have two entries in my git config this way. It seems
> that git submodule update only considers submodules listed in .gitmodules.
Did you rename the name in the gitmodules file or rename the path on the FS?
>
> 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 .
This will become 'git submodule deinit --all' eventually
> git checkout branch
> git submodule init
> git submodule update
This ought to update all the submodules, sounds fine to me.
>
> 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.
In the next version there will be 'git submodule absorbgitdirs'
which moves the git dirs of submodules inside the superproject; would
a reversion of this also be useful?
>
> 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.
>>
>