0

Sorry if this is duplicate. Tried my best to search first.

My project has dependency to a GitHub repo. This repo is maintained by other people, and I have no write permission. This repo is currently API stable, so backward incompatibility is not big concern. And the repo is fairly large. git clone --depth=1 takes about 5-10 minutes. I need a simple way to

  • make sure my project is always using the latest revision (for example, git pull on my project always pulls the updates of the repo); and
  • pull the updates of the repo incrementally, because it is big.

Here are what I tried and why I discard it.

  1. submodule. Submodule is well known for its static nature. Since the repo is stable, I do not need the static nature. I do not want to pollute the log with dummy messages.
  2. subtree. I do not want to pull this big code base to my repo. Also, I have no need to contribute back.
  3. clone. As mentioned, clone takes too long. Better be incremental.
  4. remote and archive. I think GitHub does not support archiving. Both the SSH and https URL fail.
  5. post-receive hook. Is this a viable approach? I need more knowledge to evaluate this.

It is hard to believe I'm the only one to have this issue with git. Please correct me if I misunderstand any of the approaches.

Thanks for help.

Reci
  • 4,099
  • 3
  • 37
  • 42
  • 1
    I dont understand your concerns with the (1) submodule. What log pollution you are referring to? I'm pretty sure that you will not get logs from submodule unless you explicitely ask for them. And what is 'the well known static nature'? it's not static, you can update it normally, just add 'recursive' option to fetches. Have you actually tried it that way, for example, on a purely-local clone? – quetzalcoatl Jul 03 '14 at 19:58
  • Reading through items 2-3-4, well, that's exactly what submodules are designed for.. IIRC, a submodule can even be a shallow clone (depth=1) if you wish so. Sorry, I can't grasp why did you discard that option. Can you explain? – quetzalcoatl Jul 03 '14 at 20:01
  • 3
    Also, since version 1.8.2 submodules can [track branches instead of commits](http://stackoverflow.com/a/1778247/354577). – ChrisGPT was on strike Jul 03 '14 at 20:21
  • @quetzalcoatl, [this](http://somethingsinistral.net/blog/git-submodules-are-probably-not-the-answer/#difficulty-of-use-aside-whats-the-harm) is what I meant about log. My project had lots of commit like "Updating submodule foo". – Reci Jul 03 '14 at 20:25
  • @Chris, I will try submodule with branch tracking. If it solves my problem, I will take it as answer. – Reci Jul 03 '14 at 20:26
  • @Chris, submodule with branch is good (I gave you a vote up). Nice git add the support. Unfortunately, our CI machine is Red Hat 6 and has only git 1.7.1. Looking for alternatives... – Reci Jul 03 '14 at 23:54
  • Before 1.8.2 there was no easy way to achieve what you desire. That's why branch tracking for submodules was introduced. You should consider upgrading. – Sascha Wolf Jul 04 '14 at 10:01
  • I guess so. @Chris, can you post your comment as answer? Thanks! – Reci Jul 04 '14 at 21:12
  • possible duplicate of [Git submodules: Specify a branch/tag](http://stackoverflow.com/questions/1777854/git-submodules-specify-a-branch-tag) – ChrisGPT was on strike Jul 04 '14 at 23:23

1 Answers1

0

Ever since Git version 1.8.2, submodules can track branches as well as commits:

# add submodule to track master branch
git submodule add -b master [URL to Git repo];

# update your submodule
git submodule update --remote

If you update your Git to version 1.8.2 or later you should be able to take advantage of this feature.

Community
  • 1
  • 1
ChrisGPT was on strike
  • 127,765
  • 105
  • 273
  • 257