Logic for handling git dependencies

[adityakalia]

No description provided.

[webmaster128]

Let's add this comment since git-fetch-with-cli can be necessary in cases of public git dependencies too sometimes.

Suggested change

	# Being required for gcc linking
	# musl-dev is required for gcc linking.
	# Adding Git for usage within projects that use `git-fetch-with-cli = true`.

[webmaster128]

Reopened to trigger Circle CI checks

[maurolacy]

Suggested change

	[ -n "${GIT_CREDENTIALS=""}" ] && echo "$GIT_CREDENTIALS" >~/.git-credentials && git config --global credential.helper store
	[ -n "${GIT_CREDENTIALS:=""}" ] && echo "$GIT_CREDENTIALS" >~/.git-credentials && git config --global credential.helper store

[webmaster128]

I wonder if this feature is fundamentally conflicting with the goals of this repository. Once you support private dependencies, you give up reproducible building for anyone who does not have the credentials. When you don't care about reproducibility, you can as well use a build script like this:

# compile all contracts
for C in ./contracts/*/
do
  echo "Compiling $(basename "$C")..."
  (cd "$C" && RUSTFLAGS='-C link-arg=-s' cargo build --release --target wasm32-unknown-unknown --locked)
done

and run a local wasm-opt on the results.

Here is another project that shows how things get simpler and fancier if you are building a tool for a different use case: https://github.com/mandrean/cw-optimizoor

I'd like to avoid adding overhead here (in code, text and review capacity) that at the end of the day builds proprietary build systems. And we should clearly define goals and non-goals of this repo.

[webmaster128]

Closing because private dependencies means you can't do publicly verifyable builds