How can we improve Azure DevOps?

no-fastforward merge from pullrequest

The `Merge` button in pull requests should be able to do a merge commit (--no-ff) instead of a fast-forward merge.

52 votes
Sign in
(thinking…)
Password icon
Signed in as (Sign out)

We’ll send you updates on this idea

Vegar Vikan shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

We recently made a change to cause all PR merges to be performed with the —no-ff option. Some of the comments below indicate a desire to choose between no-ff and ff merges, and while we don’t plan to bring back the ff merge option, we do have work underway to enable squash merging as an option. In the future, we also plan to add rebase options to rebase a topic branch onto the head of the target branch.

Matt Mitrik
Program Manager, VSTS

23 comments

Sign in
(thinking…)
Password icon
Signed in as (Sign out)
Submitting...
  • Steve Maine commented  ·   ·  Flag as inappropriate

    Fast-forward merges help keep the commit graph clean between multiple release branches. Please bring back this option.

  • John commented  ·   ·  Flag as inappropriate

    no-ff is a barrier to adoption of VSTS. Our default merge policy is actually the opposite: ff-only.

    Please justify why you are deliberately limiting Microsoft's market-share in this way?

  • fredgate commented  ·   ·  Flag as inappropriate

    This change is bad. We need to have the possibility to do a fast-forward merge.
    We like to merge the pull request of user story (on develop/master branch) with a merge commit, but we like to merge the pull request of task (on user story branch) as fast forward.
    Please provide this option, it is vital to keep a clean and readable history !

  • Alex Kostyukov commented  ·   ·  Flag as inappropriate

    When will you fix this? How should I use tfs prs, if I cannot setup basic workflow. Definitely we should have --no-ff by default.

  • Nikhil commented  ·   ·  Flag as inappropriate

    could you please provide the version in which this issue is been fixed? is there a specific bugfix patch which for this change which can be applied on existing TFS server?

  • Anonymous commented  ·   ·  Flag as inappropriate

    We do not like this change. Small bugfix commits with pull request ends up in 2 commits. even if ff merge is posible.
    please give us the ff posibility back.

  • fredgate commented  ·   ·  Flag as inappropriate

    This is a breaking change.
    We always merged our commits on develop branch using pull requests. That was fine as it allowed us to set up code review and to keep a clean linear history.
    Now with this change, our history can be no longer linear ! Should we abandon pull request from TFS ?
    Please : provide an option to allow fast forward and do not impose changes (without discussions) that compromise the way of working of a team since months.

  • toby net commented  ·   ·  Flag as inappropriate

    I have a same issue like following question with messages.

    http://stackoverflow.com/questions/31259314/improve-tfs2013-pull-request-merge-success-rate/31348721

    > Merge failed. This merge cannot be completed on the server. You will need to merge locally then push to the server.

    I almost resolve failed mergings **on local** git client now.
    It is too frustrated me.

    Other services can merge on pull request automatically like Github, BitBucket....

  • Matt Oswald commented  ·   ·  Flag as inappropriate

    Yeah, this is annoying. I would prefer fast-forward merges, and would definitely prefer it if there was an option.

  • Andrew Schwartzmeyer commented  ·   ·  Flag as inappropriate

    This absolutely needs to be an option. Some of us really *don't* want --no-ff merges because it can double the number of commits to an integration branch. I need to be able to turn this off.

  • James Meyer commented  ·   ·  Flag as inappropriate

    I haven't seen it called out explicitly, but it seems like now (as of a week or two ago, where 3 weeks ago it was definitely still doing FF) all pull requests resolve with a commit merge, no fast forwarding (even when fast forwarding was possible)... I hope this was intentional and won't be rolled back, but this is perfect for me! I don't see an option anywhere to choose one way or the other, though, and never saw it mentioned in any patch notes, so I'm a LITTLE confused and worried it might be pulled back, but for now, I'm happy!

  • Joe commented  ·   ·  Flag as inappropriate

    Any chance this feature will be included in the new TFS 2015? Does anybody know?

  • Petro Sasnyk commented  ·   ·  Flag as inappropriate

    With July 17 update pull requests merged manually on PC with --no-ff are shown as abandoned instead of completed as before.
    So they not added support for --no-ff, but even broken existing functionality.

  • Todd commented  ·   ·  Flag as inappropriate

    I, too, would like to see a --no-ff option during merge. If you follow git flow or the so-called GitHub flow, you typically want no fast forward. Most git clients give the option during merge. Without this flag, VSO pull request merge is out of the question. I end up merging locally, which results in my pull request showing as having Abandoned status. It would also be nice to have the option to close the branch. These flags could also be set during the creation of the pull request, like Bitbucket does (BB allows the close branch option to be selected).

  • James Meyer commented  ·   ·  Flag as inappropriate

    This is huge for me. VSO already does this if FF is not possible; this should at the least be a repo-level option, but I don't see why it can't be an option per pull request (technically, that is).

    I can see why some users/groups might not want to use this if FF is an option, but for my use case, it is critical, and I am having to always go back to Git to check if VSO did a merge commit, and manually create one if it didn't. It is a HUGE pain and prevents me from trusting delegation of this to others.

    Fast forwards kill the branch history, and we handle everything with a slightly modified GitFlow process, using feature branches heavily. Some of these branches get dozens or potentially hundreds of commits, and once you do a fast forward, you lose visibility into what was just merged, so rolling it back is both hard to do (have to roll back a lot of commits), and sometimes impossible to determine what and when it was actually merged in.

    How many +1's can I add for one idea?! I have been hoping for this for the last year, and still nothing. The new features to require branch commits to go through pull requests is great (for us), and requiring a set review count, etc, but this prevents me from adding the requisite merge commit when VSO thinks it doesn't need to (unless I go in and turn the block off temporarily to allow me to do it, then turn it back on). That is too much overhead, so I basically can't use the feature at all until forcing merge commits is enabled... PLEASE!!! I'm begging, add this as an option, even if it is buried and hard to get to... maybe not many will implement, but I can't imagine this being overly difficult technically (especially compared to the complexity of many other things I'm seeing go in... the no-ff flag is already intrinsic to Git, so it seems like it comes down to just defining an option and checking on it during the shell to Git... obviously, real implementation may make it far more complex than I'm imagining, but my gut says it should be a fairly simple implementation and I'm hoping it gets some notice)

← Previous 1

Feedback and Knowledge Base