7

I am really frustrated about using git's submodule feature. Either I still don't get it right or it just don't work as I am expecting this. Following project situation is given:

Project
  | .git
  | projsrc
  | source (submodule)
  | proj.sln

In this scenario source is pointing to another repository containing the common source data across all our projects. There is a lot of development happening under source as also under projsrc. Unfortunately Project points to some commit of the source submodule and not to the actual HEAD of it. This is the usual git behaviour, as far as I got it know.

I already found out that

git submodule update

just get the version of submodule which was commited together with the main Project. However, I would really like to be always up-to date with the submodules development, but do not have any real clue how to do this right. Hence my question is:

Is it possible to attach the Project to the HEAD of the submodule, reagardless of the fact if this will break the compilation of Project or not. I just don't want to go always into the submodule directory and do git pull there. Since I think I could loose my changes done in the submodule directory, because this is simple attached to a commit and not really to any branch or so.

Please consider following constraints:

  • Developers in our group are not that familiar with all VCS around. We are used to use really huge svn repository before, without any external repo features at all.
  • We are working on Windows
  • A click'n'forget solution would be best, since most of project members are rather scared by using a command line interface :)
Cœur
  • 37,241
  • 25
  • 195
  • 267
cgart
  • 235
  • 2
  • 8
  • 1
    See also http://stackoverflow.com/questions/1979167/git-submodule-update/1979194#1979194 and http://stackoverflow.com/questions/3131912/why-are-git-submodules-incompatible-with-svn-externals/3132221#3132221 – VonC Oct 28 '11 at 11:51
  • "I could loose my changes done in the submodule directory, because this is simple attached to a commit and not really to any branch" It's not true! There is always a branch. You never lose your changes until you commit when you're in detached head state. – Vanuan Oct 29 '11 at 12:19

3 Answers3

8

The reason why a submodule points to a particular revision is important. If you point to a HEAD, builds will be unreproducible. I.e. if you checkout yesterday's a version of the Project, you would never know which exact version of source@HEAD was yesterday.

That's why it always stores particular revision sha.

To pull all submodules you could use Easy way pull latest of all submodules

Community
  • 1
  • 1
kan
  • 28,279
  • 7
  • 71
  • 101
  • I fully agree that they would break, however I am ok with that situation. I just get bothered to explain every non-git-familiar developer collaborating on my **Project** that the submodule **source** does not work as they expect it. They have always commit/push on the source on any change there. And more important, if they just do _git submodule update_ in the Project, they loose all their changes made to _source_, since they get overwritten by that particular revision. – cgart Oct 28 '11 at 11:28
  • `submodule update` doesn't delete any changes, as I know, it just checks out referred revision. The made changes are still in repo, and you could checkout them, then update **Project** to refer the revision and commit the submodule revision reference to the main project. – kan Oct 28 '11 at 11:40
  • In deed git do delete your changes if you haven't commited and pushed them yet (as also haven't pushed the changes in the parent). Since the source/ is a submodule with detached HEAD (default behavior) git submodule updates would always bring the source/ directory in the state pointed by the parent repository. This is, in my eyes, very bad behavior of git, since it doesn't even notify me that my local changes get overwritten (git 1.7.7) – cgart Oct 28 '11 at 13:53
  • If changes are not committed, `submodule update` doesn't change anything (at least it is so on my pc). If changes are committed, they are not lost, you can checkout them even it you checked out something else. Moreover, what's for you are calling `submodule update`? – kan Oct 28 '11 at 14:16
  • You can still cd to source and do checkout head. Moreover, if you commit changes to source, you would need to push them to origin. You should consider source as a simple git repository, nested into projsrc. It is what submodule really is. The only difference is that projsrc has information about origin of source submodule and specific commit. If you want your common source is always the same version as other projects, you should place all your projects in the same repo as common. – Vanuan Oct 29 '11 at 11:14
2

I am not good at Git and submodule. But I think some simple rules would be very helpful.

  1. Commit and push from sub-directory.
  2. Go back to root of your project, check the status if you need to commit and push again.

when Pull. can try to use script to bundle the "pull/submodule update" together. And only do it at the root of your project.

Enze Chi
  • 1,733
  • 17
  • 28
2

Consider this:

  1. source is pointing to HEAD (as you would want).
  2. you make changes to source inside you Project (you commit but not push them)
  3. now you have two HEADs : one in your Project's source, another in your common source.

Which one you would want to be present in your Project when you make submodule update?

The problem (and the main feature) of git in your case is that you consider commit and push as atomic operation. It isn't. Git is decentralized. There is no common HEAD. You might have multiple repositories with different HEADs.

Consider this:

  1. you have 3 developers (A, B and C) with a git project.
  2. they all pull a project's HEAD.
  3. each developer has made changes to project
  4. now each of them has 3 HEADS: A HEAD, B HEAD and C HEAD.

Which HEAD you consider "true" HEAD?

So, to answer your question: If you want common source submodule always be synchronized with central repository, git isn't your choice. And probably none of VCSs would help you with that.

You should treat git submodule as a thirdparty library which should be updated manually with these two steps:

  1. Pull your submodule ("download thirdparty library")
  2. Commit your project with updated submodule ("place the new version of thirdparty library to your project")

If you want to make changes to submodule you should do the same in reverse order:

  1. Commit your submodule ("make your changes to the thirdparty library")
  2. Push your submodule ("send your changes to the thirdparty library maintainer")
  3. Commit your project with updated submodule ("place the new version of thirdparty library to your project")
Vanuan
  • 31,770
  • 10
  • 98
  • 102
  • Thanks Vanuan. Yes, I know I got the idea of git. You might be right, it might not be the right choice. The problem is, that it took for me very long time to understand what git is actually doing compared to previously used svn. I am already really afraid about explaining this to my co-developers... Nevertheless, I think I've found already my workflow using git. – cgart Oct 31 '11 at 09:53
  • Don't be afraid to explain. Git is as simple as distributed versioning can be. The one thing your co-developers have to understand is that each copy of git repo is self-contained local "svn-server". The need of synchronization between "servers" is the reason why some things are not possible with git. – Vanuan Nov 01 '11 at 19:29