how to fork and record patches to foreign projects

meister meister at temple.edu
Mon Mar 19 15:45:55 UTC 2018


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 at 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
> 




More information about the clasp-devel mailing list