> On May 21, 2016, at 11:24 PM, Daniel Sank <sank.dan...@gmail.com> wrote:
>
> That does leave the question of whether you want people to use merge commits
> or to rebase their branch on the latest master before merging so that you
> always get a fast-forward.
Github will never fast-forward, and I never want to see anyone using a client
manually push a fast-forward to master, either. Every left-parent commit
should be something that was code reviewed.
If the changes on master are small, it's fine to just merge master into the
branch. But, in the case of larger changes and resurrecting stale, old PRs,
rather than merge 1000s of commits off of master, I actually prefer creating a
new branch from current master and merging the old branch into it.
Rebasing an entire branch on master creates new commits that were never tested
by CI, and never present in anyone's working copy. I strongly prefer to avoid
this. Rebase is great functionality, but IMHO there is only one correct way to
use it: rebase --interactive, carefully vetting each commit to ensure it still
says what you want it to.
-glyph
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
