Git commit to common submodule (master branch)?

Short answer: cd ProjectFooBarCommoneSubmodule git checkout master git commit --all -m "Lots of fixes" 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 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.

Short answer: cd ProjectFooBarCommoneSubmodule git checkout master git commit --all -m "Lots of fixes" 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 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.

Thanks, I saw that chapter. Sadly I didn't find a clear answer my question. You say there is no automatic use master, so what if a common subproject, let's say a library, updates?

Isn't a git submodule update going to update all projects relying on that library? I'd like to do the same but update that library directly from any of my main project. If that's not possible, what would be the alternative?

– Wernight Aug 28 '10 at 23:39 Git repositories do not contain any info about who has cloned them. This is why it's impossible to push out changes to all clones. Making things simple, I think you're expecting something like symlinks, so anything would be propagated immediately, while clones are more like "tar, gzip, copy, unzip".

The key is probably to just publish the changed revision number in Foo and Bar. Anyone fetching changes will see the changed revision number the next time. Anything better than that, I would say, no.

I would be glad to be proven wrong in this, though. – Kai Inkinen Aug 29 '10 at 6:11 Sure clones have to make a update or pull manually. My question is, how to?

Two projects, not clones, sharing a common code in a Git submodule. Is there any other choice than ProjectFoo commits submodule to detached head, then ProjectBar (NOT a clone) merges the changes (if that's even possible, I don't know where those changes are stored). – Wernight Aug 29 '10 at 7:36 Seem much more clear.

Could you just write some details about your section git checkout master? It's the part where after a git commit I'm in a detached head and cannot update "master" branch simply. – Wernight Aug 30 '10 at 8:06 If you do a checkout master, you say that you want to work on this current branch.I.e.

The next commit will be the head of master, when you commit, and it will also show up on upstream. Compare this to doing a checkout on a tag. In this case the tag will not move, if you change and commit, so it's a detached head.So the submodule detached head is basically a tag.

It points to revision, and will move only if explicitly asked to. When you do the checkout master, you actually select a branch to work on. The commit in the main project again "tags" the revision to be used in the module.

– Kai Inkinen Aug 30 '10 at 19:13.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.