Use Git submodule for 3rd party code

[blochberger]

Instead of using a custom shell script which could also checkout a newer version of nodejs/http-parser which breaks compatibility with this project lets make use of those cool existing Git features.

The joyent/http-parser repository redirects to nodejs/http-parser so lets use that directly.

[azadkuh]

yupp, that's right!,
update-dependencies.sh in current repo does nothing special, but like many others I don't like submodules (aka sobmodules!) and prefer bash or python scripts.

• http-parser api is quite stable and if they break the api, not only qhttp but many others also break.
• hopefully bash is available everywhere, even in Windows (by git itself)
• imho managing and maintaining submodules by such scripts is simpler than git submodule.

thanks for reminding me about joyent -> nodejs,
i won't reject this idea (or subtree) and will wait for other opinions.

[blochberger]

I prefer using submodules, as with scripts I always end up analyzing what it does before actually executing it.

[mrdeveloperdude]

my vote: scripts > submodules

[RafalNiewinski]

Yea, me too, I am voting for scripts.

[Ri0n]

I was trying to embed qhttp into my project which already uses submodules.
I didn't want to change anything in qhttp directory to not break updates but because of this shell script I had to write my own qmake project file for qhttp outside.

so my vote to submodules. and flexibility of project file should be improved anyway.

[azadkuh]

@Ri0n
you won't break anything by running current script if you are intended to use qhttp as a subproject.
by the simple .gitignore provided in qhttp, building or updating the repo does not mess things up (at least in theory and my use case)

[droidmonkey]

You could have both. Keep your script which will init the submodule. Those that know git's quirks will do it correctly without the script. It also lets you define a specific branch or tag if desired.