Explicit "mark as merged" option in pull request UI

[isaacs]

Pull requests are automatically marked as merged when the commits are not modified before pulling them into the main branch.

However, for repos that receive a lot of pull requests, the option is to either (a) have an excessive number of merge commits, or (b) force pull requestors to continually rebase on the lastest upstream, or (c) rebase/cherry-pick/am the patches on my repo, and forego the "merged" data point.

In many cases, (a) is unacceptable. Merge commits are used for specific cases, and "fixed a typo in a doc" is not worthy of the added noise.

If you are merging, let's say, 10 pull requests in a single day, then (b) is also unacceptable. I can tell all 10 people to pull, rebase, and force-push, however: 1) this is very tedious, as I have to wait for users to do this, and often explain how, etc. and 2) it creates a race condition if all 10 people do this, because they will have to do it again after I've merged one of their commits.

So, we fall back on (c) and, due to the impossibility of automatically determining whether a pull request was merged, it looks like Node doesn't accept patches.

It'd be great if I could explicitly indicate in the UI that a pull request was merged, so that the data could be more accurate.

[aredridel]

👍

[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.

[silverjam]

👍

[piedar]

👍

[tonybruess]

👍

[germanop]

👍

[tkiran]

+1

[tkiran]

👍

[patcon]

Great idea @glasser! Created a new issue: #88

[gnarf]

👍

[tonybruess]

How do we get this to the attention of GitHubers?

[gnarf]

¯\_(ツ)_/¯ - I just used twitter: https://twitter.com/gnarf/status/378211055932936192

[gnarf]

I remember at least one github talk talking about "TDD: Twitter Driven Development"

[intgr]

Edit: D'oh removed silly text, thanks to @rlidwka for pointing out that this isn't GitHub's official tracker.

+1

[rlidwka]

Maybe if we annoy GitHub developers enough with +1s they will implement it just to get some peace.

This isn't an official github issue tracker, so there are no gh developers here to annoy. Sorry. :)

[cvrebert]

👍

[davecgh]

👍

[carlosmmelo]

👍

[bel2125]

+1

[mcshaman]

+1

[mslipper]

👍

[sylvia43]

👍

[jmarshall]

👍

[pdilyard]

👍

[FilipZawada]

Can't you have an anteroom (alternatively pullrequests) branch, only for pull requests? You can then cherry-pick commits you're interested in to your develop branch from there. This allows you to:

• Use inviting green merge button and have fun of it
• It's clearly visible which PR were merged, which not
• You can accept a PR early, while spending time on cherry-pick and squashing later (once you got time). This way you give feedback to PR creator asap.

anteroom would be just a tmp branch which could be force cleaned on a regular basis.

[ramnes]

👍

[purpleidea]

+1 and for maintainers who want to automate the rebase+merge, I've created git cherryfetch

https://ttboj.wordpress.com/2015/03/16/fancy-git-aliases-and-git-cherryfetch/

Hope this helps, even if @github isn't showing it.

[leachdaniel]

+1 when doing manual via command line I cannot close as merged, without it merging again in the UI

[fregante]

If I understand it correctly, I don't think this is necessary any longer. GitHub now allows you to rebase or squash directly from the UI, so you can "merge" the PRs without having having the useless merge commit. 👍

[purpleidea]

@bfred-it unfortunately when you click via the webui it also modifies the commits! try it yourself, you'll see github signs them itself, in fact, quite different from if you use the cli. It's just junk.

[fregante]

How can it not modify the commit? The only way to get a commit onto a branch without modifying it is to have the same base. If you open two PRs from master and then merge one (ok, without modifying it) the second one will be modified. You can't merge without rebasing it... right?

[purpleidea]

@bfred-it A simple fast forward should occur in many situations but doesn't. Try it yourself.

[fregante]

As I said, that only works for the first merge, but not for consecutive ones:

❯ git checkout -b test
❯ git commit --allow-empty -m "test"
[test 3573e328] test

❯ git checkout master

❯ git checkout -b test2
❯ git commit --allow-empty -m "test2"
[test2 6ce85395] test2

❯ git checkout master

❯ git merge test
Updating b3859c62..3573e328
Fast-forward

❯ git merge test2
Already up-to-date!
Merge made by the 'recursive' strategy.

The first one is fast forward, the second one isn't:

❯ git log -3 -U
commit 28163afe030afe2b5b8d156af52e5ab71e881884 (HEAD -> master)
Merge: 3573e328 6ce85395
Author: Federico Brigante <[email protected]>
Date:   Fri Mar 9 15:43:00 2018 +0700

    Merge branch 'test2'

commit 6ce85395d2b1e77cc765419ac232254c2058ce84 (test2)
Author: Federico Brigante <[email protected]>
Date:   Fri Mar 9 15:42:37 2018 +0700

    test2

commit 3573e32877e3be7255054d17259add9df2bcfda4 (test)
Author: Federico Brigante <[email protected]>
Date:   Fri Mar 9 15:42:21 2018 +0700

    test

[jhurwitz]

@bfred-it #95 is why I prefer to merge via the CLI.