2

Background

In our start-ups documentation, we got this:

Difference between a pull request and an issue page

In a nutshell, an issue page should only include information and discussion about the issue itself (ie clarifying requirements, suggesting edits to the requirements etc) It should never include any information or data about the actual solution.

The PR page, on the other hand, should only include data/discussion about the solution. It should never include any information about the nature of the requirements, that should only be in the issue page.

Why?

b/c the issue and its solution are two different things. Issue requirements should be fixed and clear, whereas the same requirement may have many different solutions and solution paths. So a proposed solution should be hosted separately from the issue page, as we don’t want a proposed solution to influence the requirements of an issue. For example we can assign a task to an engineer, and they can spend a week and present a solution that’s absolutely not acceptable. With that solution being hosted on a separate PR page, we can cleanly reject that solution and simply assign the same task to another engineer etc.

Question

Given the above, does it make sense to be able to create a PR without having branches at all? While none of the major git based online project management tool players allow it (I checked github/gitlab and bitbucket), in theory it can be done if I fiddle with the code of gitlab.

Update (adding to answer below)

I really liked Karl Bielefeldt's answer.. I just wanted to add this: Since the project we're working on has a very aggressive release and deploy cycle, there is little tolerance for stubbed code being added to the main branch. To address that, I think it makes sense to create R&D PRs against a topic branch, where the output wouuld be a discussion, google docs etc, plus some stubbed code, and eventually when the implementation happens (which should then remove the stubbed code and replace it with actual code).. the PR for that can be done against master branch.. and everyone wins :)

enter image description here

6
  • 6
    I don't understand what you are asking. I have two questions. First, why don't you have branches? In Git with the services that you mention, you always have at least one, and probably two (remote and local) branches. Other branching schemes are almost required if you want to scale to multiple developers (which is the only time you can use a PR, since otherwise you'd be opening and closing the PR on your own). Second, what would a PR without changes to the repository look like? The whole point of a PR is to look at changes that are proposed to a branch and accept/decline them.
    – Thomas Owens
    Commented Mar 14, 2017 at 12:14
  • 3
    A pull request is nothing more than asking someone to pull your code. If you have no code , there's nothing to pull. Commented Mar 14, 2017 at 12:17
  • I wonder if the 'PR page' is a document, rather than an actual PR itself
    – user232573
    Commented Mar 14, 2017 at 13:34
  • No the PR page is the pr page itself
    – abbood
    Commented Mar 14, 2017 at 13:55
  • In that case I'd pretty much expect we're talking about what karl says in his answer- branches without code rather than than no branches. I think a tag may be enough to be a difference in order to create a PR.
    – user232573
    Commented Mar 14, 2017 at 15:32

2 Answers 2

6

You don't need changed code to open a pull request, but you do need a branch, because the intent is to eventually push some code, even if that intent doesn't always materialize.

Using a pull request to communicate about implementation details before you start coding has a couple of big advantages over a mailing list. It allows you to subscribe only to the bugs or features you are interested in. This is useful both for maintainers on large projects who must split up the work and for third parties who are only interested in one or two upcoming features or bug fixes. You don't have to filter through the entire mailing list just to see what interests you.

Also, your implementation discussion is forever associated with the commits in version control, so if people have questions about why it was designed that way, or what alternatives were discussed and discarded, it's easy to find the discussion to refer to.

For these two reasons, opening a pull request with an empty branch is becoming more and more common in the newer, larger open source projects, at least for the features that require extensive implementation discussion. Kubernetes is a good example. Github even has features like task lists that make this sort of work flow easier.

3
  • 1
    Unfortunately that isn't yet allowed by GitHub or gitlab or bitbucket
    – abbood
    Commented Mar 14, 2017 at 14:05
  • You can push small amounts of code, like interfaces, stubs, or documentation, and discuss that before beginning the large changes in earnest. Commented Mar 14, 2017 at 17:01
  • good stuff.. please see update to my answer
    – abbood
    Commented Mar 15, 2017 at 3:38
1

No. The main point of what you have quoted seems to be to keep the solution and problem separate. This does not require an actual pull request before code is written; any proposal discussions can be kept in a separate document (which I suspect may be what the docs mean by PR page).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.