How to merge from a pull request into master without closing the pull request

Question

Say I have a branch, demos, which exists to create demo code against whatever is in master. I want the commits to the demo branch to ping everyone pretty frequently, generally by being part of a pull request.

That is, I created the branch demos and the initial commit for the branch, and then made a pull request from it. I'd like to merge it to master but also leave the pull request open, so that as new commits are pushed, they just become more commits on that same pull request.

It doesn't seem like this is easy to achieve -- once I manually merged from demos into master, it automatically "closed" the pull request on github. But now I'd like to add some more changes to the same demos branch, and commit & push, just simply have it ping everyone who cares about demos as part of that same pull request.

Since it's not easy to do this, it makes me think it is wrong. Sometimes doing the easy thing is wrong in git (like using pull) but the rule is often that if you're going out of your way to do something that git doesn't naturally do, then you're probably using it wrong.

I want to handle this case in a way that is considered good by the git community and best practices. But at the same time it seems like a pretty obvious use case: a pull request to alert other to pick up changes from the branch, but not to consider the request 'complete' after the merge. An on-going pull request.

I could generate a new pull request all the time, but then it doesn't keep the different demos commits logically connected together in terms of how it all displays on github and alerts people. At the commit level, changes to demos are different from each other and may be very different things even from different authors. But at the pull request level, I'd like it to look like "all the time when anyone has stuff to push through demos it comes via this one pull request."

What's the deficiency of that workflow, and why is it not an option when merging from a PR in git?

Longueur

Just after reading the title, can't you do git checkout master; git merge branch/with/pull/request? – Pottage

This closes the open PR automatically. Maybe there's a setting to disable that? – Longueur

How did I never notice this..... – Pottage

I encountered the same problem. I want to merge an intermediate result to 'develop' branch, not killing the PR with all the conversations – Lanciform

You can re-open the same PR after pushing more commits to the branch. I don't know if it's possible to automate it though. – Raphael

Answer 1

I'm not entirely sure I follow, but I don't think that a single pull request is the ideal way to handle your use case. Github pull requests are a Github feature, and they've made them so that once that commit is merged into the repository it closes that PR.

A pull request, by virtue of the name, is a request to have a specific set of commits pulled into that repository, and it automatically closes itself off once they're merged in.

If you're on Github, an Issue may suit your needs to co-ordinate this, and you can reference that from each pull request. If you're on a different bug tracking system like Bugzilla or Trello or whatever you want, a long running ticket there would probably be best.

This might not be that accurate because I'm not entirely sure I followed what you're trying to do, apologies if so.

Pyxidium

It's the "automatically closes them" part that I don't get. Why isn't there an option to leave the PR open after merge? Yes, the PR originally refers to one chunk of commits, but maybe later I'd like the same on-going, never-ending, always-pending PR to refer to whatever more commits happened in that branch. It provides a nice place for the commits to be linearly visible and it is easy to configure to ping everyone. – Longueur

Of course, I can just use separate PRs for each time there's a block of commits to share on that branch, but then they seem like disparate events rather than one organic stream of growth in the same area of code. – Longueur

A pull request is a request for a specific, finite set of commits to be merged into the main repository. A long running set of merges is better handled in a different feature, like a bug tracking ticket or Github Issue, because by definition a pull request is completed once the commits it refers to have been merged in to the repository. Note that you don't have to merge it in to master, you could merge into demo and then merge that into master later on, keeping demo live on the repo with the log of those commits. – Pyxidium

I do think you're trying to shoehorn a use case into the wrong place based on my understanding, though. Issues on Github handle references to Pull Requests and don't change or close unless the Pull Requests have 'closes #<whatever>' or 'resolves #<whatever>' in them or words to that effect. – Pyxidium

Coming back to this question 8 years later - I still find it fascinating that PRs force a certain notion of hygiene on the user. While I certainly know the benefit of small, concise, singular-purpose PRs (and advocate they are used that way), it also feels weird to define them as only being used that way. In software maybe more than any other field, there are so many unusual, but perfectly valid, ways to solve problems. I am firmly in support of both good hygiene solutions and lots and lots of freedom for individuals to define what that looks like for them on a use case by use case basis. – Longueur

Answer 2

Have you tried, from master, to checkout all files from demos branch? This will move all files into staging area and you can commit in master. I mean...

git checkout master
git checkout demos ./path
git commit -m 'feat: merge code from demos without merging'

This will make your PR empty, but I think PR will remain open.

Inhabitancy

Answer 3

As there is no accepted solution, I'll suggest this for anyone else that might be looking for something similar. Take a look at GitHub's Webhook feature, I think it is a better fit for what the OP is trying to achieve than pull requests. Using it you can report the commits to another system like AWS SNS, twitter, IRC, etc, that the watchers can subscribe to for updates.

A list of third-party service hooks cane be found at https://github.com/github/github-services/tree/master/lib/services

Tracey