On the deprecation of issue to pull request conversion

[cbeams]

I recently updated hub, and was dismayed to see this new warning introduced in 4f70dd1:

$ git pull-request -i 321
Warning: Issue to pull request conversion is deprecated and might not work in the future.
https://github.com/spring-io/sagan/pull/319

My team and I use issue-to-pull request conversion as a core part of our workflow. So useful is this feature that we call it out in our contributor guidelines, and incite developers to install hub on the merits of this functionality alone.

Issue to pull-request conversion is a great way to evolve all the way from a question to a discussion to a committed contribution, keeping everything in context in a single issue. It would be a shame to see it go. If anything, I'd hoped that this workflow might be further promoted to first class status in the web UI as well.

Can you expand on why this is being deprecated? I realize that hub is not responsible for this change, but is rather a decision being made at the API level. Who can I lobby to reconsider that change?

[cbeams]

See this Stack Overflow thread, in which the questioner asks how one can change the base branch of a pull request—functionality I have also desired many times.

Related to the topic at hand, it seems that this useful feature was also once available in the API, but subsequently removed. Again I wonder: why?

[hkdobrev]

There is a big discussion about that here: 4f70dd1

[mislav]

Some hubbers on that thread weighted in on why we don't suggest using this API feature anymore. It might get removed in API v4 for the same reasons. Why support a feature that we don't condone using?

But this deprecation warning in hub is mostly my decision, despite the API itself continuing to be functional in v3. I don't want people using this feature, so I threw in a deprecation warning. I realize that some individuals/teams organized their workflows around this, and this is precisely why I decided to deprecate the feature with a warning on stderr: to motivate them to stop this practice and adjust their workflow in a way that it doesn't need converting issues to PRs.

So in the end, this debate is the battle of different workflows. Obviously, I and the other maintainers of hub will design it in a way that it discourages workflows that we consider harmful, even if you don't. You have options, though:

1. You can continue to use hub and ignore the warning on stderr
2. You can silence the warning on stderr by wrapping hub pull-request in a script
3. You can fork hub for your team.
4. You can code up your own script for making pull requests and distribute it with your project so all maintainers and contributors can use it. If it uses API v3, it's guaranteed that the conversion functionality will continue to be available to you.

[abourget]

Why is it harmful ? Links ?

[mislav]

@abourget 4f70dd1#commitcomment-5105733 (see my comments on that thread as well)

[alexchandel]

I get the error:

Error creating pull request: Unprocessable Entity (HTTP 422)
Not allowed to change field "issue"

when trying to do this. How do I force hub to use the v3 API? I do not want to waste another issue no, since A issue was created to update a URL, and A commit is required to do so.

Edit: There may have been confounding variables, but this was possibly fixed by checking out the head branch and/or putting the -h and -b arguments in quotes and/or completely specifying the [[owner/]repo:]branch syntax.

[mislav]

@alexchandel hub uses and will continue to use the v3 API. I sounds like you worked around your issue. The initial validation failure that you've got might have been a misleading message; sorry about that.

[mislav]

The hub pull-request -i deprecation warning has been removed https://github.com/github/hub/releases/tag/v2.7.0