#1694: try using fast fowards when accepting pull requests ------------------------------------+--------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: confirmed Priority: optional | Milestone: Component: EinsteinToolkit thorn | Version: development version Resolution: | Keywords: ------------------------------------+---------------------------------------
Comment (by rhaas):
For example, rewriting history when accepting a patch into the main repo
means that the user's repo containing the original patch now has a conflicting history, forcing this user either to deal with this, or to abandon all branches containing this patch. I usually have a feature branch with my proposed submissions, and have locally already merged that branch into my master (since I want the changes). If the main repo now changes the patches, then I'll often be forced to handle spurious merge conflicts, in particular if I have several feature branches open.
I usually find bugs etc. while developing a new feature, which takes a while to finish before I can propose it. When finding a bug, I then (usually) create a new branch on top of origin/master that contains just the bugfix then propose that fix. As such, at least in my common workflow, the branch in the merge request is a throw away branch anyway, and rebasing creates no more conflicts than merging but keeps my history cleaner (since the commit with the bugfix only appears once, assuming that rebase properly skips it as "already applied".).