try using fast fowards when accepting pull requests

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.

   • 2014-11-07T09:29:50+00:00
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.

   • 2014-11-07T09:55:30+00:00
3. 

   Ian Hinder

   • changed status to open
   • removed comment

   • 2014-12-09T13:45:48+00:00
4. 

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

   • 2015-01-25T11:36:26+00:00
5. 

   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.

   • 2015-01-26T08:56:46+00:00
6. 

   Roland Haas reporter

   • changed status to resolved
   • removed comment

   • 2015-01-26T09:11:48+00:00
7. 

   Roland Haas reporter

   • edited description
   • changed status to closed

   • 2019-02-21T19:50:27+00:00
8. Log in to comment