A TUI Git client inspired by Magit
github.com
github.com
$ save This is a commit message no quotes
“Squash before merge” workflows seem to be more common these days and I have to think it’s mostly a push by people who do not know how to do interactive rebases and history rewrites.
But it’s okay, I gave up trying to convince people. So I’ll just disagree and commit (pun intended).
If your PRs are small and you interact with git a lot using some web portal it sort of pushes you this way.
Much more useful to me than the messages is the changeset file name highlighting so I can see which files I’ve touched for the thing I’m trying to accomplish right this second. Pushing resets that. So the push is based on “I’m thinking about a new thing now”. Often my commit messages are “x” because there is no cohesion to anything since my last push, I went around making a bunch of nit picks while exploring some code path(s).
If it works for me and my team, it’s the right way. Same for everyone else.
I rarely see that documented in comments because it changes constantly, and documentation tends to be for users. An issue number can have that information, but if you're going to be tracking changes in git anyway why not use the system as designed so people don't have to hop to a different system to get a quick understanding of the commit?
There is user documentation and there is technical documentation. Both are very different. Unless you have a lib, framework or such, in which case it's more or less the same.
> but if you're going to be tracking changes in git anyway
Yes, it's a technical system for tracking changes, not documenting those changes on the developer-level.
> so people don't have to hop to a different system to get a quick understanding of the commit?
Because for any meaningful complex product you need to do that anyway. commit-messages are just the bare minimum of ways to document. Though, of course, you can make more use of it, including it in some semi-automatic changelog and such. But usually it's not worth the hazzle.
Documenting changes is part of tracking them. Yes, there is the code itself, but explaining those changes allows for following the development path. Do you expect everyone to read every line of code to understand every commit?
> commit-messages are just the bare minimum of ways to document
Single-line messages, yes. Multi-line commit messages are plenty for commit messages because they let you add more context about the changes.
I'd like to point out that it's possible for there to be multiple commits for a single issue - maybe the first one didn't fix it, or maybe there's multiple components being fixed. Simply pointing back to the issue won't give enough relevant information about each commit, it will simply say what the group of commits as a whole is supposed to do. If it turns out that fixing that issue caused others to occur, then the individual commit messages are going to be more useful for diagnosing the new problem than a single lump issue conversation will be.
I agree that there should be more documentation for a project than just git commits, I just think you're wildly estimating how useful commit messages really can be.
Do you expect everyone to read every commit? I get the impression you have the wrong focus.
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/
Also how do you resolve conflicts?
Or is this just your solo project with zero users so you dont have to worry about other people's commits or your own commit's quality?
The final review happens in the merge request-view on the forge. There is little reason for local reviewing. Especially when multiple people work on a branch.
> Also how do you resolve conflicts?
Editor.
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.
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.
I may try to play with tig as I'm always looking at different tools. Occasionally I even run into game-changers when trying these things.
Tig is the only well-known git TUI that does this, making it the only git TUI that works smoothly with Vim.
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.
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).
> 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.
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/De...
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
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.
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).
ANSI VT100 was for what system interrupt happens when you press "ESC".
The CUA standard is at a higher level in the "stack": it is about the user interface commands, shortcut keys, etc a program will provide as to have a user interface that users will already have some idea how to work with based on their existing knowledge of having worked with other programs that follow CUA. Things like using Shift+Ins to paste text for example, pressing F1 would show help, F5 would refresh the currently viewed contents (if that makes sense), F10 would open the menu, Enter activate a dialog box's default action, Escape cancels of the dialog box, etc.
These are not mutually exclusive - or even related really. You can have a program that uses the VT100 to implement a CUA interface.
It's also explicitly a Human Interface Guideline, whereas ANSI terminal standards are just interoperability instructions on how to drive a character terminal and declare nothing about how to actually use them for application UI.
Just my opinion but maybe a more unique name would help ?
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.