Recursively git pull for all git submodules is simple
My personal repository has some repositories as submodules. And the next command
$ git submodule foreach git pull origin master
ran into the following result right after entering the ruby repository because the ruby repository seems to have no master and "git pull" is stopped.
Entering 'rails'
From git://github.com/rails/rails
* branch master -> FETCH_HEAD
Already up-to-date.
Entering 'roo'
From git://github.com/hmcgowan/roo
* branch master -> FETCH_HEAD
Already up-to-date.
Entering 'ruby'
fatal: Couldn't find remote ref master
Stopping at 'ruby'; script returned non-zero status.
So my question is: Should I make a script to do this? I hope only one command line from git will do this. what should I do to git pull for all of submodules only by git command?
source to share
git
submodules are usually in HEAD-disabled states, and hence git pull
cannot figure out what you mean when it comes to the merge phase. If all you are trying to do is get the latest changes in the repository, give it a try git submodule foreach git fetch
. If you want to update each submodule master
to the corresponding one origin/master
, you can follow along git submodule foreach git checkout master; git submodule foreach git merge origin/master
.
Then, of course, you need to decide which version of each submodule you want to use in your main repository (I would not recommend blindly going with origin/master
all the time - it can be unstable - better to choose a known version, a good tag or whatever), check these versions in submodules and follow appropriate git add
and git commit
in its main repository.
source to share
Git 2.18 (Q2 2018) can avoid this bug by improving git submodule update
what affects git submodule pull
.
" git submodule update
" tries to do two different kinds of " git fetch
" in the reverse store to get the commit tied on its way to the submodule, but it fails erroneously if the first kind (i.e. normal fetch) fails, and the second one is the last to resort to one (i.e. i.e. getting the exact commit object by object name) is inefficient.
This has been fixed.
See Commit e30d833 (May 15, 2018) by Stefan Beller ( stefanbeller
) .
(Merged with Junio C Hamano - gitster
- in commit a173ddd , May 30, 2018)
git-submodule.sh
: try to get a submoduleThis is the logical continuum fb43e31 (submodule: try to get the needed sha1 by fetching the sha1 directly, 2016-02-23, Git 2.8.0) and fixes it as some assumptions were wrong.
The commit says:
Unless
$sha1
was part of the default fetch ... thefetch_in_submodule
failure here assumes it onlyfetch_in_submodule
terminatesfetch_in_submodule
when the back end does not support fetching with sha1.There are other glitches as to why such sampling might not work, such as
fatal: Couldn't find remote ref HEAD
what can happen if the remote side doesn't declare HEAD and we don't have a local refspec.
Non-HEAD advertising is permitted by the protocol specification and can occur if, for example, HEAD points to an unborn branch.
A lack of local refspec fetch can happen when submodules are fetching superficially, since then git-clone does not set the refspec fetch.
So try even more
is_tip_reachable
with the submodule, ignoring the first fetch exit code and relying on the next oneis_tip_reachable
to see if we tryis_tip_reachable
again .
Note: The error message when fetching a submodule has been improved with Git 2.22 (Q2 2019)
See commit bd5e567 (March 13, 2019) by Jonathan Thane ( jhowtan
) .
(Merged by Junio C Hamano - gitster
- in commit 32414ce , 09 Apr 2019)
submodule: clearly explain the failure on the first try
When cloning with a
--recurse-submodules
super project in which at least one submodule with HEAD points to an unborn branch, the clone looks something like this:Cloning into 'test'... <messages about cloning of superproject> Submodule '<name>' (<uri>) registered for path '<submodule path>' Cloning into '<submodule path>'... fatal: Couldn't find remote ref HEAD Unable to fetch in submodule path '<submodule path>' <messages about fetching with SHA-1> From <uri> * branch <hash> -> FETCH_HEAD Submodule path '<submodule path>': checked out '<hash>'
In other words, first, the fetch is performed without hash arguments (ie HEAD fetch), which results in the error "
Couldn't find remote ref HEAD
"; then the fetch is done using the hash, which succeeds.This commit improves the notification to make it clearer that we are repeating the fetch and that previous messages (in particular, fatal fetch errors) do not necessarily indicate that the entire command has failed.
source to share