how to fork and record patches to foreign projects

[Sky Hester]

There’s a handy version-control discipline proposed on the District Data Labs blog, written by Vincent Driessen.

http://nvie.com/posts/a-successful-git-branching-model/ <http://nvie.com/posts/a-successful-git-branching-model/>

Would that sort of model be appropriate for the requirements you are outlining? Some of your specific ideas are formalized there.

-Sky

> On Mar 19, 2018, at 9:14 AM, Attila Lendvai <attila at lendvai.name> wrote:
> 
>> 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).
> 
> -- 
> • attila lendvai
> • PGP: 963F 5D5F 45C7 DFCD 0A39
> --
> “If there's a book you really want to read but it hasn't been written
> yet, then you must write it.”
> 	— Toni Morrison [same with software — François-René Rideau (Faré)]
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/clasp-devel/attachments/20180319/51d38582/attachment-0001.html>