<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">There’s a handy version-control discipline proposed on the District Data Labs blog, written by Vincent Driessen.<div class=""><br class=""></div><div class=""><a href="http://nvie.com/posts/a-successful-git-branching-model/" class="">http://nvie.com/posts/a-successful-git-branching-model/</a></div><div class=""><br class=""></div><div class="">Would that sort of model be appropriate for the requirements you are outlining? Some of your specific ideas are formalized there.</div><div class=""><br class=""></div><div class="">-Sky</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 19, 2018, at 9:14 AM, Attila Lendvai <<a href="mailto:attila@lendvai.name" class="">attila@lendvai.name</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" class="">Yes - let’s do this. So every forked library gets a ‘clasp’ branch.<br class="">Can we then stop using specific commit hashes in the wscript file?<br class=""></blockquote><br class="">yes (but see below).<br class=""><br class="">we can also use the two combined in the build-refactor: a (branch,<br class="">commit) pair to point to a specific revision, yet remain under a named<br class="">branch. this is better, because it avoids a 'detached head' state in<br class="">the cloned repo, which makes certain operations troublesome. (if you<br class="">'git checkout [commit hash]', then the git repo gets into a detached<br class="">head state, where e.g. git log is meaningless).<br class=""><br class="">i suggest that all the commits that are meant for inclusion in the<br class="">upstreams to be recorded in feature-branches, from where PR's can be<br class="">opened to the upstreams.<br class=""><br class="">this way the 'clasp' branch can be "polluted", i.e. it may get all<br class="">kinds of merge commits, etc.<br class=""><br class="">if the 'clasp' branch ever gets a git push -f (rewritten history)<br class="">though, then the build script will have a hard time to switch<br class="">revisions. that can be dealt with, but probably better to avoid this,<br class="">because:<br class=""><br class="">i'm not sure getting rid of the specific commit hashes is a good<br class="">idea. that specific revision of the clasp codebase expects that<br class="">specific commit/revision of the dependency (as opposed to the current<br class="">head of its 'clasp' branch). if you ever want to do something like git<br class="">bisect, then you want the build script to work with a specific version<br class="">of the dependencies.<br class=""><br class="">ideally, we should have reproducible builds, where the build output<br class="">artifacts only depend on the source repo state that was used to<br class="">initiate the build. this is a far cry for such a complex system like<br class="">clasp, but applying whatever is feasible of this philosophy is useful<br class="">nevertheless.<br class=""><br class="">i can implement this cleanup of the repos after the build-refactor has<br class="">been merged (and when you're available on IRC for quick questions<br class="">regarding the status of the repos).<br class=""><br class="">-- <br class="">• attila lendvai<br class="">• PGP: 963F 5D5F 45C7 DFCD 0A39<br class="">--<br class="">“If there's a book you really want to read but it hasn't been written<br class="">yet, then you must write it.”<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>— Toni Morrison [same with software — François-René Rideau (Faré)]<br class=""><br class=""></div></div></blockquote></div><br class=""></div></body></html>