Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

There are serious problems with git submodules. This article, however, is simply concentrating on "you can forget to do X or not understand Y, in which case you can cause yourself minor irritations", which is just silly: if you understand how to use submodules all of the problems in this article go away and get replaced with more serious issues like "the submodule update mechanism doesn't get rid of obsolete submodules", "submodules can only exist in the root folder", "the mechanism for migrating between different upstream sources of a submodule (which will happen: this is a distributed version control system) require coordination with people using the code", and "for many people, who are attempting to use this in a context of a unified company, the lack of a solution to moving code back/forth between submodules makes moving to git a major step down from Subversion, where the subtree repository support made it entirely reasonable to store an entire organization's worth off projects, with binary art assets, together in a single master repository".


git submodule add <remote> <subpath/into/the/project> will create a submodule in a subfolder.


Ah, touche: I forgot that that one was just an issue with the tool and not a fundamental limitation. (Sadly, the same kind of "that isn't a real problem: just a 'you don't know enough'" that I'm complaining about from the article ;P.)


I think that the issue is that <subpath/into/the/project> always has to be relative to the root directory. You can't do something like:

  % cd subpath
  % git submodule add <remote> <into/the/project>


  > a major step down from Subversion, where the subtree
  > repository support
You could always checkout git-subtree. The functionality is there under the hood in git (git-subtree is literally a shell script, though not a minor one).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: