On 04/14/2015 06:50 PM, Matthew Taylor wrote:
I think I looked into that and decided it wouldn't work (feel free to
prove me wrong). Git submodules are included at a specific SHA, and
we'll need to have git repos that continuously get updated.
I see, you would need a trigger anytime any of the repository gets
updated, without any manual integration / human intervention.
Indeed, submodules won't do that to my knowledge.
For the record, "git submodule update --remote --merge" [1] would update
all submodules, so the manual steps would be limited to "pull -
submodule update - push".
Cheers,
Rémi
[1]: http://www.git-scm.com/book/en/v2/Git-Tools-Submodules#Submodule-Tips
Indeed, the first step in those shell scripts are pulling the latest code from
upstream, then turning around to push code. Submodules are not well
suited for development in this fashion, IMO.
---------
Matt Taylor
OS Community Flag-Bearer
Numenta
On Tue, Apr 14, 2015 at 9:28 AM, Rémi Emonet
<[email protected]> wrote:
On 04/14/2015 06:16 PM, Matthew Taylor wrote:
But if we could prevent these shell calls and local repository
checkouts (perhaps by using the GitHub Git Data API), then we could
move to Heroku.
Hi Matthew,
I don't have any time to look at the build in details but if, I understand
the problematic, git submodules could be a solution.
https://devcenter.heroku.com/articles/git-submodules
Cheers,
Rémi
