aka the mess in clasp-developers.
a few thoughts that may be useful:
when we fork a repo into clasp-developers, i advice to create a branch in it called 'clasp', or some specific name of a new feature, i.e. *not* the master branch.
git checkout -b new-branch
if new patches are needed from upstream master, then *rebase* the extra patches to the newly pulled master. don't merge the branches, because that quickly renders git-commit based comparison useless.
first make sure you don't have pending changes. if you have, then you can use this to save/restore them:
git stash git stash pop
then:
git checkout master git pull master git checkout my-branch-to-be-rebased git rebase --verbose master
if some problem happens, you can either:
git rebase --abort
or fix the conflict by hand in the working copy, and then:
git diff git add whatever-changed.lisp git status # to see that everything has been staged git rebase --continue
if you want to drop some patches while rebasing, then do:
git rebase -i master
and then just delete the relevant lines in the editor that pops up, then save, and quit to continue.
this is especially useful when a parallel branch/fork is expected to be open for a longer time.
the current cffi and its master branch is a good example of what shouldn't be done.
---
IMO, avoiding merge commits in general is a good idea, unless it's really a significant merge that you want to keep recorded in the history, or if you want to GPG sign the merge commit.
you can also attempt a fast-forward pull, e.g. when dev was pulled into master:
git pull --ff-only . some-other-branch
this may fail without changing anything in the repo if it's not possible to pull without a merge.
when you accept a PR, then on github you can chose the rebase option on the merge button. then the commits just get copied over into the master branch, as if they have been committed there to begin with.
---
random note: the new version of git-fetch-revision.sh in the build-refactor branch supports cloning branches other than master, and even specific tags.
hth,
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? Those have been a thorn in my side.
Best,
.Chris.
On Mar 19, 2018, at 11:40 AM, Attila Lendvai attila@lendvai.name wrote:
aka the mess in clasp-developers.
a few thoughts that may be useful:
when we fork a repo into clasp-developers, i advice to create a branch in it called 'clasp', or some specific name of a new feature, i.e. *not* the master branch.
git checkout -b new-branch
if new patches are needed from upstream master, then *rebase* the extra patches to the newly pulled master. don't merge the branches, because that quickly renders git-commit based comparison useless.
first make sure you don't have pending changes. if you have, then you can use this to save/restore them:
git stash git stash pop
then:
git checkout master git pull master git checkout my-branch-to-be-rebased git rebase --verbose master
if some problem happens, you can either:
git rebase --abort
or fix the conflict by hand in the working copy, and then:
git diff git add whatever-changed.lisp git status # to see that everything has been staged git rebase --continue
if you want to drop some patches while rebasing, then do:
git rebase -i master
and then just delete the relevant lines in the editor that pops up, then save, and quit to continue.
this is especially useful when a parallel branch/fork is expected to be open for a longer time.
the current cffi and its master branch is a good example of what shouldn't be done.
IMO, avoiding merge commits in general is a good idea, unless it's really a significant merge that you want to keep recorded in the history, or if you want to GPG sign the merge commit.
you can also attempt a fast-forward pull, e.g. when dev was pulled into master:
git pull --ff-only . some-other-branch
this may fail without changing anything in the repo if it's not possible to pull without a merge.
when you accept a PR, then on github you can chose the rebase option on the merge button. then the commits just get copied over into the master branch, as if they have been committed there to begin with.
random note: the new version of git-fetch-revision.sh in the build-refactor branch supports cloning branches other than master, and even specific tags.
hth,
-- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Chaos should be seen as a teacher that teaches us, through the negative, what not to do.” — Mark Passio, http://youtu.be/atjdCbayxYM?t=46m33s
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).
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@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é)]
sounds reasonable to me.
(you can start reading at "Decentralized but centralized", the rest is noise)
-
Attila Lendvai -
meister -
Sky Hester