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