2

I have many sub -repos, meaning one big umbrella repo that has smaller repos. Now when I do a commit in a leaf repo, it will automatically mean that I get a change in its parents. If you suppose the structure as a binary tree, you may realize it is ridiculous -- having 5 git-repo deep structure could easily mean $ git commit -m 'did 1'; cd ..; git commit -m 'did 1 as mentioned'; ... git commit -m 'did 1 same as earlier'. How can I avoid this kind of repetitive committing?

Example 1: a graphical example about the problem

X---------|
          |
Y---------A --------|
                    |
          B --------|<-----Pictures (graphic designers, animators--have repo)
                    |
          C --------|

A change in Pictures will change A, B, C, X and Y -- bloated commit, 6 commits due to one change, bad repetition! Now people working with Pictures can be totally different people to people doing things with X,Y, A, B and C, making things more obscure.

Example 2: hand-on -example to trial with sub-sub... -repos

Please, copy this hand-on -example here. You can test things there with 3-level -sub-repos.

So far Suggested

  1. The basic submodules in Git, more here.

  2. Gitslave here.

Community
  • 1
  • 1
hhh
  • 50,788
  • 62
  • 179
  • 282

3 Answers3

1

Don't create repositories within repositories. That will avoid repetitive commits. Probably will solve other issues as well.

If you really think you have a need for repositories within repositories then use submodules.

GoZoner
  • 67,920
  • 20
  • 95
  • 145
  • 1
    As @GoZoner suggested submodules are what you want. You can read up on them here: http://progit.org/book/ch6-6.html – asm Apr 09 '12 at 19:49
  • Where is 'children directory WWW' relative to 'Hello'? – GoZoner Apr 11 '12 at 21:15
  • 1
    As GoZoner pointed out we don't know what 'WWW' is, but once submodules are configured your file structure should be identical to what it is now. The only difference will be how you commit things. Now that I think about it, you'll still have to commit multiple times with submodules, you'll just be committing submodule changes instead of actual files. I don't think there is a way to do what you want without multiple commits of everything. – asm Apr 11 '12 at 21:26
  • Are you asking for the steps to turn the current sub-repository into a submodule? – GoZoner Apr 27 '12 at 12:46
  • @GoZoner I currently rm the repo or move it else where, do stupid commit and then add the thing back to make sub-repo into sub-module, one commit agani, not sure whether the right way -- getting one extra commit, bad? – hhh May 13 '12 at 20:51
0

It is possible that your design or structure is poor, perhaps the premise behind GoZoner's command "Don't create repositories within repositories.", but it is also possible that your project has come to a point requiring more powerful tools. There are times when basic submodules are not enough and your repos too broad, then you should probably look at -- GitSlave! It is a workflow -tool in which you specify your super -repo and then the slave repos. Instead of repetitive commiting, you use the gits -command -- manual here.

Related threads

Community
  • 1
  • 1
hhh
  • 50,788
  • 62
  • 179
  • 282
0

Do the files in your repositories often come with associated changes with other files in other repositories? If so, multiple repositories is not your friend. You should only use multiple repositories when they are completely (or almost completely) independent of one another.

On the other hand, if they are completely independent, then you can just use separate repositories. Then, to build some sort of master project that might use files from each repository (ie, it depends on the other repositories) then you use a submodule.

A repository being a submodule of another repository means that it depends on that submodule. Dependency-links between submodules is probably a bad idea if the API is not stable, but if the API is stable so changes in one won't directly impact the other (ie, no code changes necessary), then two top-level submodules can depend upon each other.

Now, I've been talking about submodules the whole time, but an alternative exists called "subtree" if you want to check that out to see what you prefer. Its in the contrib/ section of the main git repository so it isn't installed by default. Also there exists the subtree strategy (ProGit chapter linked to in a comment)

alternative
  • 12,703
  • 5
  • 41
  • 41
  • 1
    @hhh If the source code in a deployment repository cannot change, why do you need a repository? Also, I haven't tried git-slave but it doesn't look too impressive to me; it seems like its a solution for reducing repetition rather than managing the subrepositories themselves. Oh, and `git subtree` and `git merge -s subtree` are separate entities. – alternative Aug 19 '12 at 17:11
  • 1
    @hhh Git is meant to track source code not the deployment stuff (which is a reason I really don't like Heroku all that much...). It sounds like you are using git as a deployment tool when you shouldn't be. For example, you could just redeploy tarballs or something if you want to avoid giving the developers the sources for the graphics stuff. Generally, a git repository contains the *bare minimum* required to build a project (*no* generated files, *no* ./configure [if using autoconf]), precisely because it is problematic to always update these generated files on commits and regenerate repos. – alternative Aug 19 '12 at 17:22
  • Could you differentiate the `"git subtree"` and `"git merge -s subtree"` in your answer? Git-subtree is some outside module to Git while the the name `"subtree"` in `"-s subtree"` just a placeholder? Also, I hope you review this thread [here](http://stackoverflow.com/questions/10790634/changing-permissions-with-deep-git-repository-repository-tree-with-sub-repos-an) because I am suggesting there gitslave but git-subtree may be better alternative, no idea, just novel suggestion there. – hhh Aug 19 '12 at 17:31
  • 1
    @hhh I added it to the answer already, and `subtree` refers to `git subtree` while `-s subtree` is `git merge -s subtree` (or similar merge-like command that accepts `-s` and `-Xopts`) – alternative Aug 19 '12 at 17:45
  • So this [here](http://git-scm.com/book/ch6-7.html) is not the thing you are suggesting? Sorry I cannot yet find what you mean by git-subtree? Is it an addon to git? Is this [here](https://github.com/apenwarr/git-subtree/) the git-subtree you are suggesting? Some example or scenario when it could be used? This book [here](http://git-scm.com/search/results?search=subtree) has nothing about the git-subtree, experimental feature? – hhh Aug 19 '12 at 17:49
  • 1
    @hhh The second link. But the code is in the contrib/ section of git.git. Also I'm not particularly suggesting it, but rather saying its there (iirc, it was a GSoC project last year or something. I remember the patch series being on the mailing lists, so it does have code reviews from Junio, etc) – alternative Aug 19 '12 at 18:23