Allow pull requests to be rebased from the UI

[patcon]

Forked from #2:

@glasser

Additionally, allowing you to rebase (or even rebase-and-squash) in the UI would be great, rather than needing to go into a local copy to do so. It would be perfectly fine if this only worked in non-conflicting cases.

[cvrebert]

👍

[mediocregopher]

+1

[cirosantilli]

+1 6

Another option which does not involve modifying history is merge --squash.

There are 72 votes for that on GitLab's Uservoice tracker: http://feedback.gitlab.com/forums/176466-general/suggestions/5662794-provide-squash-option-when-merging-merge-requests

Rebase was implemented on GitLab EE... http://feedback.gitlab.com/forums/176466-general/suggestions/4289653-rebase-merge-requests-in-the-web-ui (and has 92 votes)

[stucox]

Agreed, merge --squash would be better.

[tomek-brcm]

I'd prefer modified but easy to understand history over a spaghetti of branches.

[rayshan]

+1 this breaks github web-only workflow by forcing the user to switch to CLI

[tomek-brcm]

...and pull request doesn't pick up CLI rebase so the only option is to close the pull request as "unmerged" with the comment that it actually was rebased and merged from CLI.

[rlidwka]

the only option is to close the pull request as "unmerged" with the comment

just close PR from the commit itself

[tomek-brcm]

How? The pull request remains open and unmerged if I do this:

git checkout pr-branch
git rebase master
git checkout master
git merge --no-ff pr-branch
git push

[cvrebert]

So, GitHub recently added an "Update branch" button to PRs, but it sounds like it adds another merge commit instead of rebasing 😒

[sparrc]

@tomek-brcm after git merge --no-ff pr-branch you can do a git commit --amend and add Closes #NNN to the commit message. That's what I do to close PRs from CLI

[SamHasler]

This is more needed for those that open pull requests as they are much less
likely to have the project checked out or know how to use the git cli to
rebase and squash commits.
On Sep 28, 2015 11:44 PM, "Cameron Sparr" [email protected] wrote:

@tomek-brcm https://github.com/tomek-brcm after git merge --no-ff
pr-branch you can do a git commit --amend and add Closes #NNN to the
commit message. That's what I do to close PRs from CLI

—
Reply to this email directly or view it on GitHub
#88 (comment).

[tomek-brcm]

For me it boils down to the old Unix policy vs. mechanism design choice. Git is a great mechanism allowing us to choose a combination of merge, rebase, squash and fast-forward. It's also separate from the UI. The web UI mandates one, fixed policy, and policies tend to age very quickly.

It might be time to upgrade the policy to match current user requirements. Thanks to the separation between mechanism and policy it shouldn't be too difficult.

[jeznag]

This would be a great feature.

[gion]

I'm waiting for this feature for a while now 👍

[samthebest]

@dopplershift If you have an issue with merge commits cluttering up history, you should use a different tool to browse history. I tend to use git log plus grep and such and such, and I've never had any issues browsing history with merge commits.

It sounds like some weird OCD.

[dopplershift]

Glad that works for you. It doesn't for me.

Save your value judgements--I'm not asking you to do anything.

[jplebre]

@zougloub cannot endorse your point enough. Many hours wasted since this became available as someone decided to "oh but it was there seemed like the right thing to press".
If a team/organisation has a specific workflow, being able to disable/enable the options would eliminate the possiblilty of pressing the wrong button for that given repo

[ulgens]

I'm writing this from 2023, this feature is not implemented yet and nobody knows why.

[bdrazen]

Almost 6 years later. Has there even been an official response on this?

[rsp]

This is an update to my comment above (from May 2017)

Currently some CI services like Travis (but I don't think all of them) can be configured to run the tests twice - once on the PR branch itself and once on what would be the result of merging the PR to the base branch, so the problem that I described in the comment above (with merge buttons that update the target branch before running the CI tests on the result for some cases) can be mitigated somewhat if you use Travis and if you want to run the additional build (in practice I usually have to configure Travis to run the tests on both the original and the merged PR and not only on the merged PR because I need the tests on the actual branch anyway so it means running the build twice for every PR update which can sometimes take significant time).

Currently in my GitHub guidelines I recommend not to use the "Update branch" button like @pzrq in this comment above, specifically to avoid the mess that @fpagnoux and @galulex show in their comments here. (The ProjectR looks interesting but I cannot give it access read and write all public and private repository data for the projects I work on.)

[gorshkov-leonid]

Hello. I am in an hospital. But upstream's owner ask me to rebase changes before merge changes. I don't know how to do It via UI from my phone

[fkorotkov]

This feature can be added now via a GitHub action. Here are sources with instructions for the action: https://github.com/cirrus-actions/rebase. It will automatically rebase a PR on a /rebase comment.

[EwoutH]

@fkorotkov Looks very nice! But's insane there just aren't simple Rebase and Rebase & Squash buttons in the UI, especially at PR's.

Just something simple like this. One button with pull-down would also be fine.

[danielloganking]

If I disable --no-ff merges for PRs on my repository (which I do) then it stands to reason that I would not want the "Update Branch" button to add a merge commit. Can we at least get an administrative option that determines if the "Update Branch" button uses a pull --rebase or merge ? Especially considering that GitHubs own docs note that rebasing is an equally valid option: https://help.github.com/en/articles/about-required-status-checks

[tibdex]

The Autorebase GitHub App is similar to the previously mentioned GitHub Action but it can also be installed on public repos and it goes a bit further. Indeed, it doesn't stop to the one-time /rebase command, but rather makes the whole Rebase Workflow enjoyable.

[repsejnworb]

cries in 2021 and the 'Update Button' still isn't configurable to rebase instead of merge

[samthebest]

cries in 2021 and the 'Update Button' still isn't configurable to rebase instead of merge

"cries" @repsejnworb ? Don't you mean celebration? I think Github is doing a fantastic job of keeping this anti-pattern out of it's workflow.

Good on them from preventing the world from decending into a 1984 style dystopia, where force pushes are normal and history is what some developers want to see, rather than history being an accurate record of reality.

[morficus]

@samthebest how in the world is rebasing a feature branch against main/master/develop an anti-pattern?

[samthebest]

@morficus Happy to help pal! Here is the wikipedia definition:

According to the authors of Design Patterns, there are two key elements to an anti-pattern that distinguish it from a bad habit, bad practice, or bad idea:

1. The anti-pattern is a commonly-used process, structure of pattern of action that, despite initially appearing to be an appropriate and effective response to a problem, has more bad consequences than good ones
2. Another solution to the problem the anti-pattern is attempting to address exists, and documented, repeatable and proven to be effective where the anti-pattern is not

So rebase satisfies both here because

1. People who use rebase (on pushed branches) actually believe it to be an appropriate and effective response to a problem. This thread is proof of that.
2. Another solution, namely merge exists. Not only is it documented it's even natively supported by Github as a button.

I guess the issue is that the users of the anti-pattern are not aware of the bad consequences of rebasing pushed branches, like it invoking git push --force and rewriting history via patch commutation.

The fundamental problem here is, developers often falsely identify themselves with their code. So they perceive a git branch as a part of them, even after a branch is pushed. Once a branch is pushed, the branch is now non-local it doesn't belong to anyone, it isn't part of anyones identity. Therefore to rewrite that branch is to rewrite a distributed, accurate account of history. Especially troublesome for other developers who may also be working on that branch.

It's probably because some users find it hard to use git and read the git logs, because they are used to a GUI for viewing history. They think it's better to rewrite history to be easier to consume, rather than change the tooling they use to consume it.

Although the consequences are unlikely as bad as Big Brother from 1984, the principle is the same - a record of history should not be altered for the convenience of a single party, no matter how complex the history, and no matter how inconvenient for the single party.

[danielloganking]

Rebasing a branch is not inherently an anti-pattern. But even if it were, the button should still be configurable to allow repo owners to specify --ff-only merges which both satisfies a strict view about the evilness of rebase and accomplishes the desire of updating the branch parent to the new head of the target without creating a merge commit.

The fact that the "Update branch" button forces --no-ff simply makes it a footgun for projects that are trying to maintain a linear history (for whatever reason) and is at odds with all the other options GitHub has added to enable such projects.

[morficus]

@samthebest you should read the git documentation about how merge differs from rebase. they are fundamentally different and can (and do) produce very different outcomes.

Instead of trying to quote a Wikipedia article about the Gang of Four, I invite you to explore the actual differences and valid use cases of using both merge and rebase as part of a workflow in place of sticking to some artificial restrictions you're choosing to impose.

[tomek-brcm]

@samthebest Nobody's forcing you to use rebase so why force everybody to avoid it?

Secondly, there are genuine cases where the exact origin of the branch is of little importance. Most single-commit patches can easily be cherry-picked out of order. Git itself was modelled on Linux workflow. People were sending patches against the last released Linux version and maintainers applied those patches out of order on top of other, not yet released patches. It didn't kill Linux, did it? Remember the old "home taping is killing music" slogan? Your claim about the necessity of accurate history in git is equally false.

Git hub is a tool. It's supposed to make my work easier, not harder. I prefer the convenience of somewhat inaccurate history over pain of branch spaghetti "no matter how complex the history, and no matter how inconvenient". Yes, there are people who like pain, good for them. I don't so I started to avoid github. Simple.

[richardasmall]

its pretty disheartening to do a google search for something you thought would be so simple and see a thread that is now 8 years old that GitHub appears to be just completely ignoring.