Git commit to common submodule (master branch)

I’ve two or more projects (let’s call them ProjectFoo and ProjectBar) having some common code that I put in a submodule.

My understanding is that if I commit changes to a submodule from within ProjectFoo it’ll be in a detached head that only all ProjectFoo clones can see:

  • commiting to git repo from a second machine
  • Does the current path matter for some git operations?
  • Ignore file in Subversion removes old values from svn:ignore property
  • Undoing an old commit
  • Can't add a file separated with space to git
  • How can I undo my last git add/commit?
  • (master) $ cd ProjectFooBarCommoneSubmodule/
    (master) $ git commit -am "Common code fix."
    (56f21fb0...) $ git push
    Everything up-to-date

    That’s probably because the master branch hasn’t changed. I could probably do something like git checkout master && git merge Everything up-to-date but that seem pretty ugly. May be a git reset --hard master would do the same but it seems even uglier.

    How to have a common code shared by project, updated from within those projects using it? In other words, committing to that submodule should update all various repositories (repositories, not just clones) that use this same submodule.

    —- EDIT —-

    Visibly my checked-out repository was messed up and broken. It should have worked right from the start like that (on ProjectFoo in this example):

    (master) $ cd ProjectFooBarCommoneSubmodule/
    (master) $ git commit -am "Common code fix."
    (master) $ git push
       fbfdd71..0acce63  master -> master
    (master) $ cd ..
    (master) $ git add ProjectFooBarCommoneSubmodule
    (master) $ git commit -m "Submodule update."

    Then to get that change from on other projects, like ProjectBar:

    (master) $ cd ProjectFooBarCommoneSubmodule/
    (master) $ git pull

    Would update to the latest common code. A git checkout master may be required if it’s on a detached head.

  • git log not chronologically ordered
  • git checkout and git status both say I am up-to-date, but then git pull pulls changes
  • Pull from multiple, only push to one
  • Using git diff in same file between first and last commit
  • Git Fatal Error: info/refs not found
  • Can I get a list of all pull requests related to a specific file/directory path in GitHub?
  • 5 Solutions collect form web for “Git commit to common submodule (master branch)”

    Short answer:

    cd ProjectFooBarCommoneSubmodule
    git checkout master
    <Do your editing>
    git commit --all -m "Lots of fixes"
    git push submodule_origin master
    cd ..
    git add ProjectFooBarCommoneSubmodule
    git commit -m "Bumped up the revision of ProjectFooBarCommoneSubmodule"
    git push origin master

    The longer one:

    Git submodules are a dependency mechanism, where the main project (say A) defines a specified revision in a subproject (say B), which will be used in building project A. In order for the tool to be useful the behavior has to be predictable from A:s point of view. Dependencies cannot change, unless somebody decides to incorporate the change to project A. All kinds of nasty things could happen, were project B:s changes automatically imported, of which compile errors are probably the best ones, as A would notice the failures immediately. This is why B:s head is kept in detached state.

    The state of B is store in A (check out git submodule status), and a revision change has to be done and committed in A, in order for it to have any effect. This is what happens in the example above, A changes the revision number stored in the repo, and bumps up the version to the latest one. The process will have to be repeated in the other main repo as well, so no automatic “use master” switch AFAIK.

    BTW. The Git book chapter on submodules and the submodule man page contain lots of useful info about submodules, as normal usage and typical pitfalls as well. Worth checking out.

    EDIT: I’ll try to explain this better

    I took the liberty to create example projects on my github account. The commits are meaningless and contain junk, but the setup should be fine. Please check it out to follow.

    Both ProjectFoo and ProjectBar share the code in the common submodule.

    ProjectFooBarCommoneSubmodule:master is 6850e4e4c1fac49de398

    In ProjectFoo:

    git submodule status

    -6850e4e4c1fac49de39890703f21486ca04b87a0 common

    In ProjectBar:

    git submodule status

    -6850e4e4c1fac49de39890703f21486ca04b87a0 common

    So both point to the same revision, right? The trick here is to see, that ProjectFoo and ProjectBar point to the revision (6850e4e4c1fac49de39890703f21486ca04b87a0) not the branch (master), although they are the same thing. The first one is a detached head, and the other a named branch.

    If you want to do some fixing on ProjectFooBarCommoneSubmodule, you can go to the subdir in e.g. ProjectFoo, and choose the branch instead of the revision:

    git checkout master 
    <Do your coding and pushing here>

    Then go one directory up, and check git submodule status. It should tell you, that you are now out of sync. E.g

    git submodule status

    +e24bd2bf45d52171a63b67ac05cd4be0ac965f60 common (heads/master-1-ge24bd2b)

    Now you can do a git add, to set the reference to this particular commit(ge24bd…), do a commit, and after this the submodule reference points to this revision, which also happens to be master on ProjectFooBarCommoneSubmodule.

    Now you need to update the reference in ProjectBar as well. Go to ProjectBar/common, and do git fetch origin (this is a fast forward merge), do

    git checkout master 
    cd ..
    git add common
    git commit -m "Bumped up the revision"
    git push origin master # to publish the revision bump to everybody else

    So, as with any git repository, you don’t need to work on a detached head. You can either work on master, or create a named branch. Either way, make sure that upstream contains the ProjectFooBarCommoneSubmodule changes, or you will break both ProjectFoo and ProjectBar, if they reference something that doesn’t exist. Hope this explained it better

    On the submodule: git push origin HEAD:master

    If you want to commit and push all submodules at once do:

    git submodule foreach 'git commit -a' ;
    git submodule foreach 'git push --all' ;
    git commit -a && \
    git push --all --recurse-submodules=on-demand

    To merge changed from detached HEAD into master, run:

    git rebase HEAD master

    then checkout master (use -f for force):

    git checkout master

    If you’ve got multiple submodules to deal with, use: git submodule foreach, e.g.

    git submodule foreach git pull origin master -r

    I just do:

    git submodule foreach git push -u origin master

    Git Baby is a git and github fan, let's start git clone.