try using fast fowards when accepting pull requests

Create issue
Issue #1694 closed
Roland Haas created an issue

For small single change pull requests have a full git merge in the history can be annoying since it clutter the history view (it uses up two lines, it may show connecting both branches existing at the same time even if there are no commits on master during that time).

We could try and instead find out if bitbucket can be made to allow fast forwards in the pull request merge (https://bitbucket.org/site/master/issue/6106/forced-non-fast-forward-merge-of-pull). Currently apparently bitbucket uses --no-ff ie it disallows fast forwards.

We could even think about forcing fast forwards only (https://bitbucket.org/site/master/issue/9589/force-fast-forward-only-merges-on-pull). This does however not work so well for big "feature" branches that are brought back into master and where a fast forward may fail and/or require extensive rebasing of the feature branch.

Keyword:

Comments (7)

  1. Frank Löffler
    • removed comment

    Always forcing wouldn't work, as you already mentioned. Selectively doing so would be the only right way.

  2. Erik Schnetter
    • removed comment

    Our main goal should be to keep things simple for users who provide patches, and also for maintainers who accept them.

    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.

    If the problem you are trying to solve is visual clutter when looking at the repo history, then (a) this actually reflects the history, and (b) maybe the visual presentation can be improved. There must be others facing the same problem, and using fewer vertical lines, or using lines that are not vertical, or combining several vertical lines into thicker strings (for branches you don't care about) may be options.

  3. Roland Haas reporter
    • removed comment

    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".).

  4. Frank Löffler
    • removed comment

    I propose to close this ticket. This is not a good place for a discussion about suggested workflow, and there is nothing to do right now.

  5. Log in to comment