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

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

 



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.





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