-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Allow user to initiate open pull request prior to push completing #4339
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
While this would be convenient, it has never bothered me enough to want to do something about it. It's easy to see in the branches panel that the branch is still being pushed, so I just wait for the "Pushing..." spinner to go away and then press
No, this is totally not an option. We shouldn't block in controllers, this would be a very bad user experience if the branch takes long to push. We do sometimes block after performing a command, e.g. if we need to make sure that the selection is in sync again when the command has finished; for example after moving a commit up or down with ctrl-j/k. But we never block before even starting a command. So if we wanted to do this properly, we'd have to enqueue the request somehow, and return to the main loop. Then execute the request later when the branch is done pushing. Which raises the question whether we need to somehow visualize that the request is enqueued; do we need to provide a way to cancel it if you change your mind, etc. In my opinion it's not worth the complexity.
In my work repo we have quite expensive pre-push hooks that examine commits one by one. Pushing a very long branch can take minutes there. |
Perhaps my problem is that I have just gotten faster with lazygit. In my memory, there is some version of this app where I could seamlessly press I don't think it's unreasonable to keep track of your branch status and wait to hit
Got a PR up that implements that idea using a map of waitgroups that keeps track of which local branches are being pushed. The enqueueing of the It has no idea of cancellation or status updates, although that would be an interesting idea. |
@stefanhaller This idea has been stuck in my head, so I went ahead and implemented a version with both cancellation and status display! Displays pending tasks in the status bar, and uses the global Escape action to cancel those tasks while they are pending. Check it out at https://github.com/ChrisMcD1/lazygit/tree/full-background-task-capability! Don't have as a PR yet since it requires additions to the gocui fork, and I'd rather get some more feedback on the idea before making that PR. |
I'll have a closer look as soon as I find enough time, which might only be next weekend. Meanwhile, some early thoughts from a very cursory glance at the code:
|
For the record I also find it annoying to wait for the branch to be pushed before opening, so a solution would be welcome, assuming it's not too complex (afraid I don't have the time right now to look at your branch @ChrisMcD1 ). If it is too complex, another solution is to simply have a new keybinding for push-and-open, perhaps in the menu that you open with shift+o |
Split into more atomic commits, and draft PR created #4370. I am using a Also, high level question about the gocui fork... Is this meant to be a full fork alternative that external projects rely on, or is just designed for the jesseduffield universe to use? Wondering how consideration for breaking changes would work. |
Uh oh!
There was an error while loading. Please reload this page.
Is your feature request related to a problem? Please describe.
I often find myself pushing a branch and then immediately making a PR. I hit
P
and theno
, but then receive the warning that there is no upstream branch. This is factually correct, but one will exist in less than one second.Describe the solution you'd like
I would like for lazygit to realize that there is a branch currently being pushed, and to wait for that to resolve prior to actually attempting to open the PR.
For my simple case, this could probably just be solved with a simple mutex or RWLock that the
sync_controller
sets, and thebranch_controller
waits to be available right when a user attempts to open a pull request. A more complicated system could be created that tracks which branches are currently being pushed, but that feels unnecessary. I don't feel like many people are pushing branch A, and then going and opening a pull request on branch B while that happens.EDIT: ^ Actually, I think a map of locks keyed on local branch name would make a lot more sense. With stacked branches, I often actually push multiple branches at once, and then would like to be able to open pull requests on them without waiting.
Describe alternatives you've considered
The only alternative I can think of that doesn't involve coding something would be to just wait for visual confirmation that the operation has finished.
Additional context
I don't experience long push times in my daily flows, either from pre-push hooks or slow upload speeds, so I'm not sure how such a feature would impact those users.
The text was updated successfully, but these errors were encountered: