Use gitui with remote repositories
alistaircarscadden opened this issue · comments
Is your feature request related to a problem? Please describe.
I would like to push and pull from remote branches.
Describe the solution you'd like
Potentially a tab beside Status and Log called Remote, the functions would be pull, push, fetch, and anything to do with remote branches.
The functionality to push a local branch of some name to a remote branch of some other name like git push origin localdev:feature_remote should be included. I'm not a git poweruser, so I don't require much from remotes, I'm sure other people would have better ideas.
Describe alternatives you've considered
Ctrl+C to quit gitui, git push, gitui
Hi @alistaircarscadden interfacing with remote repos like clone, pull, push are rather low on my list since I don't find them benefiting that much from a UI, but maybe I am missing something
That's fair. It all depends what you expect from a git UI. In my case I imagine using a tool like this like I'd have used SourceTree before I started using command-line only. But, it's the difference between Ctrl+Cing out of the application and typing in git push origin develop or just typing [P] [Enter], or whatever it'd end up being.
As far as improving git pull with a UI vs. the command-line, I think the example I gave with having a local branch and a remote branch with different names is something that new users or users who generally use UIs would appreciate instead of having to learn the git syntax.
I'm learning Rust, closest thing I knew previously was C++, so perhaps one day I'll implement some of these suggestions. :)
Ha it would awesome if you wanna get your hands dirty yourself. After all open source depends on exactly that :)
However I totally agree in a full feature UI for git this functionality makes sense! It is definitely not a "not gonna happen in gitui over my dead body" but more a "not gonna have time for this pretty soon based on cost/benefit"
https://github.com/TimB87/gitui/commit/cc158b643f270bdc0a397425dda22dc17db91d41
It's not pretty or might not even be the desired way to go, but this worked for me.
While being in the status tab and having the staged changes area focused with commits, pressing "p" will silently push these to origin.
There is no feedback, no help item, nor any further functionality (pull, rebase, ..).
Also one caveat: i didn't find a crate that implements these commands in pure rust, so this will invoke the systems instance of git, provided that the users PATH actually has a working git installed.
@TimB87 thanks for sharing this. gitui uses git2-rs (link) to interface with git, that intern is wrapping the c-lib libgit2 which has support for push/co.
currently we are not using the ssh/https based features of git2-rs as it will make the compilation more complex. however that would be the way to go to implement support consistent with the rest of the application. its doable but for my personal requirements for gitui I have different priorities first
@extrawurst Thanks so much for the input, glad that I missed git2-rs, because I felt really cheap just invoking the system binary 😄
I will have a look around git2-rs and see if I can make it work. The biggest obstacle I see for me is actually getting a working fetch/rebase ui implemented.
That's fair. It all depends what you expect from a git UI. In my case I imagine using a tool like this like I'd have used SourceTree before I started using command-line only. But, it's the difference between Ctrl+Cing out of the application and typing in git push origin develop or just typing [P] [Enter], or whatever it'd end up being.
Hi, new to this project (not even installed yet but really interested by it) and I was expcting indeed that gitui was a "full-blown" git client and I see with this issue it is not (yet) the case :)
That's probably something you already thought of (and maybe rejected), but maybe a temporary solution would be to allow to enter "raw" git command from within gitui ?
Then that allows at least to not quit the client ?
I know this should then be a separate issue but this issue made me think of it here (I don't want to derail it further though)
maybe a temporary solution would be to allow to enter "raw" git command from within gitui
From my perspective, however that would be implemented it'd end up being the same number of keystrokes and the same level of command memorization that the original git CLI requires, and wouldn't push this application towards it's goal of being easier to use/more visual/less man page reading than the original.
It's not a bad idea, and I considered it myself, but I think it's best to not implement that and wait on a real implementation of each feature.
I agree it doesn't save keystroke, but it allows you to not quit the application. And designing and implementing correctly all the features take time, this could allow to release some "steam"
My goal is to not juggle between apps (or in and out of app).
But this is derailing this issue 😁
I can create a new one if @extrawurst wishes (or if he says directly he doesn't want this, then no need to create one I guess)
Hey @GMouron thanks for chiming in, hope by now you downloaded it 😛
This conversation made me clarify a bit more on the readme: https://github.com/extrawurst/gitui#expectation-management
The short version is: gitui is a spare time project and I love building it because it is in rust and because I piece by piece have to worry less about cryptic git shell commands. This makes me prioritise the features here strictly by what creates the most pain when not handled by the gui and push/pull unfortunately is low on the list because it has a bad pain to use via shell vs pain to implement ratio.
Of course your proposed solution would be a workaround but I must agree with @alistaircarscadden here and ask what the great benefit is of that. after all I am fine with switching between shell and gui, because gitui boots up very fast. if anything I could see a potential to optimise that even more.
I hope this clears up my reasoning a little bit. Let me know what you think.
I can totally understand that you wouldn't want to implement a possibility to enter raw git commands in gitui because it doesn't totally fit the goals you have for the tool, no problem with that.
I would argue though, that if you would do, it would allow us to win a couple of keystrokes 😁 and thus a few extra ms 😜.
One could also argue that you then don't have to ask yourself, while on the command line, if this git feature is in gitui or not (which, the more you put in, paradoxically could trigger even more that question), you would just open gitui in the morning and live within it. 👼
But I won't try further to change your mind, because I can understand that you consider it doesn't fit what you had in mind.
it would allow us to win a couple of keystrokes
In gitui if ctrl+i was the command shortcut: Ctrl+i g i t c h e c k o u t d e v Enter
In gitui currently: Ctrl+c g i t c h e c k o u t d e v Enter up enter
pain to use via shell vs pain to implement ratio
2 keystrokes per command (a couple ms a couple times a day) vs. a couple hours.
I would like to suggest that one should be able to disable any remote commands in the config or even via compiletime option. Some people might not want to use these feature by accident, so it would be nice to deny them in some way or another.
@matthiasbeyer
Would performing git remote remove <remote_i_dont_want_to_ever_push_to> work? I only ask because I'd like to better understand your use case. Are you often using repositories locally, that have remotes set up, that you couldn't stand the chance you'd ever push to it?
No, I mean I have fat fingers and am sometimes doing things in tig that I don't want to do. Pushing to a remote might be non-reversible and thus I rather do it by typing git push <remote> <branch> myself rather than having a tool do it for me!
@matthiasbeyer thanks for chiming in on this. All destructive operations are currently already behind a confirmation dialog, this would be no different IMHO
#265 adds first rudimentary push functionailty
push works:
I tried #266 and it works great over here, tested on a private gitlab repo 😃
this is superseded with #319 - we are closing in on a 0.11 release adding push/(soon pull) 🥳