7 ms·

A TUI Git client inspired by Magit

118 points by gearnode 3y ago

fernandotakai 3y ago
i don't like tuis that much (other than for editing text, i mean), but i also really don't like git's command line interface. so i've been using forgit, which basically adds a really nice fzf interface for git. it really fits the way i work within a terminal (i'm a heavy fzf user). https://github.com/wfxr/forgit https://github.com/wfxr/forgit
globular-toast 3y ago
I will try this, as I'm always looking for a good git client comparable to magit that I can recommend to non-Emacs users. But I doubt it will be comparable to magit. I started to think about making a TUI client myself, but I very quickly realised a big part of what makes magit good is that it's in Emacs. There are so many points where you need to enter/edit/select text etc. To get the power of magit you'd also need to reimplement Emacs.
- crtasm 3y ago
  Give tig a try also if you don't know it, it's been my git interface for years now.
bilekas 3y ago
I've been using `gitui` after lazygit was getting a bit slow with larger repo histories. Its been really solid. The naming on this cargo almost made me mistake it. Just my opinion but maybe a more unique name would help ?
- kuschkufan 3y ago
  Yeah same, but this gitu looks interesting too. Just from the screenshots alone I might like this interface more. Sadly not yet available through brew or nix, I'll wait.
- bombela 3y ago
  For commiting, I found fugitive (in neovim) quite good. Staying in my editor to list the changes, and select the hunks to commit is quite nice. I also found the fugitive git blame useful. I am looking at some code and I can quickly look at the recent changes. But for looking at the history in details; something I only need to do rarely; I struggled with fugitive. I never managed to use `tig` properly. And I sometimes used `git gui` and `gitk`. I recently tried (cargo) `gitgui` and I found it intuitive. It might be the one. Time will tell.
- deleted 3y ago
  [deleted]
throwaway290 3y ago
Others include lazygit, gitui, git-fuzzy. Lately I think fugitive in Vim is enough for routine work for me lately, though git-fuzzy is great when I remember about it. Doesn't need any installation (just add in path) and acts like a git command so you just run "git fuzzy".
matricaria 3y ago
If you are using Neovim, Neogit is a similar plugin. It’s my preferred way of using git. https://github.com/NeogitOrg/neogit https://github.com/NeogitOrg/neogit
federicotdn 3y ago
Nice! I tried some months back implementing a “framework” that would allow for implementing Magit-like interfaces for any command (https://github.com/federicotdn/brief https://github.com/federicotdn/brief) but at the end of the day, implementing bespoke interfaces per-command would probably allow you to better integrate with the command itself.
- aeonik 3y ago
  Emacs seems to support this already with Derived Modes. I've tried to derive Magit mode for some commands before, and it seems relatively straight forward. My main issue is that Elisp and Emacs still confuse me after 2 years of casually messing around with it. https://www.gnu.org/software/emacs/manual/html_node/elisp/Derived-Modes.html https://www.gnu.org/software/emacs/manual/html_node/elisp/De...
- funcDropShadow 3y ago
  Magit is built on such a framework. It is called 'transient' an Emacs Lisp library.
  - hprotagonist 3y ago
    which is in core now!
user3939382 3y ago
The biggest quality of life improvement for me with git is a bash function I wrote that does add all, commit and push in one. Turns out I don’t care about all the granular control it provides 99% of the time, it’s cumbersome: $ save This is a commit message no quotes
- globular-toast 3y ago
  So basically `scp -r` (recursive remote copy). It's what I call "dumb version control" and I've observed many people not going beyond this with git: https://blog.gpkb.org/posts/git-is-a-version-control-system/ https://blog.gpkb.org/posts/git-is-a-version-control-system/
  - Thorrez 3y ago
    It's better than scp because it stores the commit message and the history, and old versions are immutable.
    - globular-toast 3y ago
      Well, I'm not sure what kind of commit messages would be possible other than "update" and "new version" etc. if you're committing everything each time.
      - Thorrez 3y ago
        Wouldn't it be possible to fix a bug then commit that fix?
- rwmj 3y ago
  This is fine for using git as a kind of offsite backup, but I hope you later rebase everything into meaningful commits with proper messages if you're going to share your work with anyone else.
  - loloquwowndueo 3y ago
Asooka 3y ago
[flagged]
nobleach 3y ago
I've been a vim user for so long it doesn't even make sense to do the math to give a year. Around 2013, my buddy at work and I switched to Emacs just to try something different. We only lasted a few months. One thing that I took away from that experience was Magit. I was a CLI user of Git because all the other interfaces just bothered me. When I went back to Vim, I started using fugitive. It wasn't bad, but it just didn't have that same Magit feel that I really enjoyed. I tried the Atom text editor for about a year. It was the best Vim-emulator I'd ever seen at the time. Someone had been working on a Magit clone for it. It reminded me of how enjoyable Magit truly was. Flash forward a couple of years, I'm on NeoVim and someone starts working on NeoGit. I couldn't contain my excitement. It's cool to see someone untangle the experience from any one particular editor.
- myaccountonhn 3y ago
  Have you tried tig? Ultimately I’ve started using that instead and it works great as a magit replacement. I use it together with Kakoune in daemon mode, so I can jump in and out of files with tig and have the state with buffers remain.
  - okl 3y ago
    tig is great. One of my favourite features is that you can define your own shortcuts in the global .gitconfig. For example, when I press `=` it creates a fixup commit for the selected commit. That, together with the ability to stage single lines completely changed my workflow. Recently, I have become a bit lazy and use PyCharm to stage and commit changes. Its diff viewer also supports staging single lines but its better integrated. For example, pressing F4 jumps to the current file/line in the main window.
  - timeforcomputer 3y ago
    I love tig. I have an ad-hoc fork of it adding a new window which displays a preview of the selected file in the diff prelude section of the diff window, so I don't have to navigate through the single window. It is very helpful to browse the files in a diff easily. (https://github.com/LucasPayne/tig https://github.com/LucasPayne/tig) I swear I will clean up the fork soon, I just implemented it in whatever way worked. I do something similar to what you are doing with Kakoune daemon mode, but I work in the shell within a vim context. I have bound "e" in diff/stage views of tig to send a message to the current vim to open a new tab for that file at that line. I have not tried magit yet but am going to now to at least extract some great ideas from it and somehow get it in my current workflow.
TachyonicBytes 3y ago
How hard would it be to implement commands other than git in this client? Something like "Transient outside of Emacs", not just "Magit outside of Emacs"?
tiffanyh 3y ago
IBM CUA I really wish 5+ decades ago someone would have established a common user access standard for TUI, like IBM did for desktop (GUI) apps. TUI would be much more pleasant today if all TUI used the same menu system & keys for common actions (e.g. FILE | EDIT | VIEW and CTRL C for copy / CTRL V paste). https://en.m.wikipedia.org/wiki/IBM_Common_User_Access https://en.m.wikipedia.org/wiki/IBM_Common_User_Access EDIT: To explain further, just look at how Emacs and Vim use different commands to 'exit'. Emacs uses "C-x C-c", whereas Vim uses ":q!" Exiting an app, like copy and paste, is a very common task. Yet there is no standard in how to perform that task in TUI today. With GUI apps, we have that standard (e.g. FILE -> EXIT or on the keyboard "Alt + F4"). This standard came via IBMs CUA standard.
- actionfromafar 3y ago
  and buffered input
- badsectoracula 3y ago
  AFAIK CUA wasn't for GUI apps (i think there was even some DOS-based "demo" that used text mode), some text-based DOS programs used it (the Shift+Ins, etc shortcuts you'd find in Turbo Vision-based programs used CUA). Also what we often call "CUA" nowadays is actually Microsoft's modifications, even if it was based on IBM's (which AFAIK doesn't have things like Ctrl+V for paste but instead the Shift+Ins i mentioned above).
- reactordev 3y ago
  What? ANSI VT100 standard predates IBM's CUA. In fact, so does the VT220 standard. What's missing? https://en.wikipedia.org/wiki/ANSI_X3.64 https://en.wikipedia.org/wiki/ANSI_X3.64
  - tiffanyh 3y ago
    That wasn't for Menu layout and common actions (e.g. FILE | EDIT | VIEW) ANSI VT100 was for what system interrupt happens when you press "ESC".
jcronenberg 3y ago
The killer feature from magit which this seems to be missing is the ability to stage only a specific part of a hunk. When I make a bigger change and want to split it into different commits, magit is simply the best way to achieve this quickly. Other than that it looks great.
- signa11 3y ago
  yup magit is pretty much seamless for workflows involving both squashing commits and splitting them open as well.
theCodeStig 3y ago
One can run Emacs in the terminal. What’s the use case for this?
deleted 3y ago
[deleted]
yencabulator 3y ago
> A rough list of so-far supported features: > File/Hunk-level stage/unstage One of the key features of magit is sub-hunk level stage. If you have a diff hunk you don't want to fully commit, you can select just the lines you do want, and stage that. I use this regularly to e.g. stage most of my change but not the debug print I currently have there.

118 points by gearnode 3y ago

i don't like tuis that much (other than for editing text, i mean), but i also really don't like git's command line interface. so i've been using forgit, which basically adds a really nice fzf interface for git. it really fits the way i work within a terminal (i'm a heavy fzf user). https://github.com/wfxr/forgit https://github.com/wfxr/forgit

globular-toast 3y ago

I will try this, as I'm always looking for a good git client comparable to magit that I can recommend to non-Emacs users. But I doubt it will be comparable to magit. I started to think about making a TUI client myself, but I very quickly realised a big part of what makes magit good is that it's in Emacs. There are so many points where you need to enter/edit/select text etc. To get the power of magit you'd also need to reimplement Emacs.

crtasm 3y ago
Give tig a try also if you don't know it, it's been my git interface for years now.

bilekas 3y ago

I've been using `gitui` after lazygit was getting a bit slow with larger repo histories. Its been really solid. The naming on this cargo almost made me mistake it. Just my opinion but maybe a more unique name would help ?

kuschkufan 3y ago
Yeah same, but this gitu looks interesting too. Just from the screenshots alone I might like this interface more. Sadly not yet available through brew or nix, I'll wait.
bombela 3y ago
For commiting, I found fugitive (in neovim) quite good. Staying in my editor to list the changes, and select the hunks to commit is quite nice. I also found the fugitive git blame useful. I am looking at some code and I can quickly look at the recent changes. But for looking at the history in details; something I only need to do rarely; I struggled with fugitive. I never managed to use `tig` properly. And I sometimes used `git gui` and `gitk`. I recently tried (cargo) `gitgui` and I found it intuitive. It might be the one. Time will tell.
deleted 3y ago
[deleted]

throwaway290 3y ago

Others include lazygit, gitui, git-fuzzy. Lately I think fugitive in Vim is enough for routine work for me lately, though git-fuzzy is great when I remember about it. Doesn't need any installation (just add in path) and acts like a git command so you just run "git fuzzy".

matricaria 3y ago

If you are using Neovim, Neogit is a similar plugin. It’s my preferred way of using git. https://github.com/NeogitOrg/neogit https://github.com/NeogitOrg/neogit

federicotdn 3y ago

Nice! I tried some months back implementing a “framework” that would allow for implementing Magit-like interfaces for any command (https://github.com/federicotdn/brief https://github.com/federicotdn/brief) but at the end of the day, implementing bespoke interfaces per-command would probably allow you to better integrate with the command itself.

aeonik 3y ago
Emacs seems to support this already with Derived Modes. I've tried to derive Magit mode for some commands before, and it seems relatively straight forward. My main issue is that Elisp and Emacs still confuse me after 2 years of casually messing around with it. https://www.gnu.org/software/emacs/manual/html_node/elisp/Derived-Modes.html https://www.gnu.org/software/emacs/manual/html_node/elisp/De...
funcDropShadow 3y ago
Magit is built on such a framework. It is called 'transient' an Emacs Lisp library.
- hprotagonist 3y ago
  which is in core now!

user3939382 3y ago

The biggest quality of life improvement for me with git is a bash function I wrote that does add all, commit and push in one. Turns out I don’t care about all the granular control it provides 99% of the time, it’s cumbersome: $ save This is a commit message no quotes

globular-toast 3y ago
So basically `scp -r` (recursive remote copy). It's what I call "dumb version control" and I've observed many people not going beyond this with git: https://blog.gpkb.org/posts/git-is-a-version-control-system/ https://blog.gpkb.org/posts/git-is-a-version-control-system/
- Thorrez 3y ago
  It's better than scp because it stores the commit message and the history, and old versions are immutable.
  - globular-toast 3y ago
    Well, I'm not sure what kind of commit messages would be possible other than "update" and "new version" etc. if you're committing everything each time.
    - Thorrez 3y ago
      Wouldn't it be possible to fix a bug then commit that fix?
rwmj 3y ago
This is fine for using git as a kind of offsite backup, but I hope you later rebase everything into meaningful commits with proper messages if you're going to share your work with anyone else.
- loloquwowndueo 3y ago

Asooka 3y ago

[flagged]

nobleach 3y ago

I've been a vim user for so long it doesn't even make sense to do the math to give a year. Around 2013, my buddy at work and I switched to Emacs just to try something different. We only lasted a few months. One thing that I took away from that experience was Magit. I was a CLI user of Git because all the other interfaces just bothered me. When I went back to Vim, I started using fugitive. It wasn't bad, but it just didn't have that same Magit feel that I really enjoyed. I tried the Atom text editor for about a year. It was the best Vim-emulator I'd ever seen at the time. Someone had been working on a Magit clone for it. It reminded me of how enjoyable Magit truly was. Flash forward a couple of years, I'm on NeoVim and someone starts working on NeoGit. I couldn't contain my excitement. It's cool to see someone untangle the experience from any one particular editor.

myaccountonhn 3y ago
Have you tried tig? Ultimately I’ve started using that instead and it works great as a magit replacement. I use it together with Kakoune in daemon mode, so I can jump in and out of files with tig and have the state with buffers remain.
- okl 3y ago
  tig is great. One of my favourite features is that you can define your own shortcuts in the global .gitconfig. For example, when I press `=` it creates a fixup commit for the selected commit. That, together with the ability to stage single lines completely changed my workflow. Recently, I have become a bit lazy and use PyCharm to stage and commit changes. Its diff viewer also supports staging single lines but its better integrated. For example, pressing F4 jumps to the current file/line in the main window.
- timeforcomputer 3y ago
  I love tig. I have an ad-hoc fork of it adding a new window which displays a preview of the selected file in the diff prelude section of the diff window, so I don't have to navigate through the single window. It is very helpful to browse the files in a diff easily. (https://github.com/LucasPayne/tig https://github.com/LucasPayne/tig) I swear I will clean up the fork soon, I just implemented it in whatever way worked. I do something similar to what you are doing with Kakoune daemon mode, but I work in the shell within a vim context. I have bound "e" in diff/stage views of tig to send a message to the current vim to open a new tab for that file at that line. I have not tried magit yet but am going to now to at least extract some great ideas from it and somehow get it in my current workflow.

TachyonicBytes 3y ago

How hard would it be to implement commands other than git in this client? Something like "Transient outside of Emacs", not just "Magit outside of Emacs"?

tiffanyh 3y ago

IBM CUA I really wish 5+ decades ago someone would have established a common user access standard for TUI, like IBM did for desktop (GUI) apps. TUI would be much more pleasant today if all TUI used the same menu system & keys for common actions (e.g. FILE | EDIT | VIEW and CTRL C for copy / CTRL V paste). https://en.m.wikipedia.org/wiki/IBM_Common_User_Access https://en.m.wikipedia.org/wiki/IBM_Common_User_Access EDIT: To explain further, just look at how Emacs and Vim use different commands to 'exit'. Emacs uses "C-x C-c", whereas Vim uses ":q!" Exiting an app, like copy and paste, is a very common task. Yet there is no standard in how to perform that task in TUI today. With GUI apps, we have that standard (e.g. FILE -> EXIT or on the keyboard "Alt + F4"). This standard came via IBMs CUA standard.

actionfromafar 3y ago
and buffered input
badsectoracula 3y ago
AFAIK CUA wasn't for GUI apps (i think there was even some DOS-based "demo" that used text mode), some text-based DOS programs used it (the Shift+Ins, etc shortcuts you'd find in Turbo Vision-based programs used CUA). Also what we often call "CUA" nowadays is actually Microsoft's modifications, even if it was based on IBM's (which AFAIK doesn't have things like Ctrl+V for paste but instead the Shift+Ins i mentioned above).
reactordev 3y ago
What? ANSI VT100 standard predates IBM's CUA. In fact, so does the VT220 standard. What's missing? https://en.wikipedia.org/wiki/ANSI_X3.64 https://en.wikipedia.org/wiki/ANSI_X3.64
- tiffanyh 3y ago
  That wasn't for Menu layout and common actions (e.g. FILE | EDIT | VIEW) ANSI VT100 was for what system interrupt happens when you press "ESC".

jcronenberg 3y ago

The killer feature from magit which this seems to be missing is the ability to stage only a specific part of a hunk. When I make a bigger change and want to split it into different commits, magit is simply the best way to achieve this quickly. Other than that it looks great.

signa11 3y ago
yup magit is pretty much seamless for workflows involving both squashing commits and splitting them open as well.

theCodeStig 3y ago

One can run Emacs in the terminal. What’s the use case for this?

deleted 3y ago

[deleted]

yencabulator 3y ago

> A rough list of so-far supported features: > File/Hunk-level stage/unstage One of the key features of magit is sub-hunk level stage. If you have a diff hunk you don't want to fully commit, you can select just the lines you do want, and stage that. I use this regularly to e.g. stage most of my change but not the debug print I currently have there.