Yes - let’s do this. So every forked library gets a ‘clasp’ branch. Can we then stop using specific commit hashes in the wscript file?
yes (but see below).
we can also use the two combined in the build-refactor: a (branch, commit) pair to point to a specific revision, yet remain under a named branch. this is better, because it avoids a 'detached head' state in the cloned repo, which makes certain operations troublesome. (if you 'git checkout [commit hash]', then the git repo gets into a detached head state, where e.g. git log is meaningless).
i suggest that all the commits that are meant for inclusion in the upstreams to be recorded in feature-branches, from where PR's can be opened to the upstreams.
this way the 'clasp' branch can be "polluted", i.e. it may get all kinds of merge commits, etc.
if the 'clasp' branch ever gets a git push -f (rewritten history) though, then the build script will have a hard time to switch revisions. that can be dealt with, but probably better to avoid this, because:
i'm not sure getting rid of the specific commit hashes is a good idea. that specific revision of the clasp codebase expects that specific commit/revision of the dependency (as opposed to the current head of its 'clasp' branch). if you ever want to do something like git bisect, then you want the build script to work with a specific version of the dependencies.
ideally, we should have reproducible builds, where the build output artifacts only depend on the source repo state that was used to initiate the build. this is a far cry for such a complex system like clasp, but applying whatever is feasible of this philosophy is useful nevertheless.
i can implement this cleanup of the repos after the build-refactor has been merged (and when you're available on IRC for quick questions regarding the status of the repos).