idursun
FR: Add command to generate and follow a new pull request link
Is your feature request related to a problem? Please describe. After creating a new bookmark and pushing to a remote, the next step is often to go and request the patch be pulled / merged.
Describe the solution you'd like Using one key to generate and follow this link is very handy. Tools like lazygit and neogit make this quite simple.(those link are to the documentation on the topic)
Describe alternatives you've considered I could use a script to do this, no problem. I could even run that as an alias or custom command. I suspect, there will be users over time that seek this feature.
Why current features fail to cover this request I can't promise that they do, but I haven't found the option at least.
I'd be willing to implement such a feature maybe, only if this is desired by @idursun and in accordance with other design goals.
Hey thanks for the suggestion @theherk
The version in the main now has flash messages, which is basically showing output of the ran command as a flash message on the side. Link to the PR is here: #206
This includes showing the git push command output too.
Currently, error messages are stick (needs to dismissed by pressing esc) and the success messages disappear after 4 seconds.
What I am not sure about is if the git push and git fetch output messages should also be sticky even though they are successful because they usually contain important information as you described.
Does making git push command output sticky cover your use case? (as it usually contains a link to the PR)? or do you have a more general use case in mind?
I'm not sure if that link comes back in all git host cases, though it may, but that is up to the host. If it does, that still requires following the link via clicking if available in that terminal context. In addition, this link will only be available at initial branch push time, and one might wish to create the request after pushing a few more commits or just generally in the future.
But what you say would absolutely help in many cases.
In addition, this link will only be available at initial branch push time, and one might wish to create the request after pushing a few more commits or just generally in the future.
True!
Having support for generating a link to PR on demand doesn't hurt IMO. Feel free to give it a go. 👍🏿
Does making
git pushcommand output sticky cover your use case?
Maybe not the right solution for this issue, but it would also be nice to have a way to show previous flash messages. Many vim distributions or other editors have a way to show "notifications" that were already closed by the popup timer. I could work on this if it makes sense to you.
Yeah, but that is slightly solving a different problem. Just like when you close vim, then content of messages and notifications are gone (though you can of course persist them to disk), you'd run into the same thing here. jjui has a session and its responses from calling git are ephemeral, unless persisted to disk somehow. Meaning you'd still only get one shot at this, only in that session, and still only with git hosts that return the url. So I think a solution like lazygit might be nice.
I think it can be closely related to the bookmark or git interfaces. So, a git option to open request would know sane defaults for public services and allow configuration of non-standard ones. This would generate and open a url to create a pull request for the currently selected bookmark, whether or not the git host has returned this url or it has done so in an earlier session.
Yeah, but that is slightly solving a different problem.
Oh yes, I know. That's why mentioned that it would be a nice to have: Being able to see previously closed notifications. Not as an alternative to solving this issue, but I was responding to @idursun about output of commands being sticky. I would prefer to have a way to open closed notifications than non-errored outputs being sticky.
I think it can be closely related to the bookmark or git interfaces.
That makes sense to me. Having a shortcut on the git interface to show/open the url of PR
Fair enough. On that topic, would it be best to persist for the duration of the session or to disk? Seems to me the former is a fine expectation but the latter might be opening a can of worms.
but the latter might be opening a can of worms.
totally agree, I opened #243 for discussion and avoid getting off-topic here.