> I use git on the CLI 99.9% of the time. I never used a GUI for git and don’t see a reason to.
Nobody needs a gui for git or a text editor but using magit is like a superpower compared to the command line. It is probably the best piece of software i've ever used. you can even drop down to the command line git inside of it if you need. i don't understand why anyone would prefer the cli over it.
Exactly. My favorite is probably "r s" or rebase subset: it is much more intuitive to use than remembering the order of the refs you pass to `git rebase --onto X Y Z`, and this happens to be something I do a whole lot since I use dependent branches to create dependent PRs.
I'm not sure your point? I am advocating for magit/a text editor plugin. git itself is not a TUI either like say lazygit is one. if someone were to rip out everything except magit and throw it into a TUI I'd be down to use it but as it is I only use emacs for magit because magit is just that good.
gitkraken is nice yeah. it's nowhere near the efficiency of magit imo. git is like ed. magit is like vim. gitkraken is more like maybe word? does everything you want has a nice clickable gui but it is not quite as efficient to use.
> I use git on the CLI 99.9% of the time. I never used a GUI for git and don’t see a reason to.
Because it shows more information about the state and spares you the trouble of navigating much of the zoo that is git cli design
For example,
> It shows the current branch and whether the repository is dirty, i.e. whether it has uncommitted changes
And the GUI would also show what/where those changes are and allow jumping to edit them. And you'd get updates after you edit even without manually refreshing the prompt
> spares you the trouble of navigating much of the zoo that is git cli design
Yeah. I understand the inner workings of git and am perfectly capable of using git on the command line but the git cli is just so horribly designed. I regularly have to google how to perform rather basic actions because the cli just isn't structured in any sensible way.
> When someone asks me to help them with some git thing
I point them at jujutsu (jj) and then they simply get on with using source control without the need for 8,000+ articles about navigating the insane Git command line interface.
Good article. I'm both using git in CLI and graphic tools. But atm the thing that GUIs have and none of the cli is the navigable git graph. And I do like seeing the graph.
I also love clicking on the current branch name, seeing all available branches and the checkout in an instant. 0 typing.
Or select files by intuitively pressing + on them (or their folder), go through all the changes on the side.
From these threads it seems that I'm the only one who appreciates some UX and not having to type literally everything every time I've got to do something on a computer.
Regarding the formatting of commit messages: if everyone on your team is doing things slightly differently is something going wrong and what could fix it?
Is it a respect issue: people don’t follow a consensus because everyone is a headstrong individualist who refuses to play along with others?
Is it a communication problem? Are people just not intermingling in the commit message culture enough that they all naturally converge on a house style?
Is it a leadership issue? Are there no clear leaders in your engineering team who collude — consciously or subconsciously — to set the tone for everyone else?
Is it a technical issue? Without a pro-forma commit message template or additional tooling, are you failing your eng org by not giving them the framework / training wheels / guard rails they need to align on a house style for technical documentation?
I’ve been part of very healthy teams who largely ended up self organising into a consistent house style with a little help from tooling. I’ve also been part of unhealthy teams who fork themselves into multiple internal cliques that don’t intermingle enough to build up a monoculture. The healthiness of the teams might correlate with the commit message / commit graph style, or it might not. I wonder how it could be done better.
Specifically the commit formatting? How to write and markup?
A lot of people don’t care enough. Likely someone will be on your team. And if they all care then it might still be the case that they won’t have a house style. Because it’s still well-written and legible.
Yeah, commit message formatting as a proxy metric for how closely aligned your engineers are. Another one might be “do they all dress kind of the same?”
Lots of successful teams literally dress identically (Real Madrid, Biles et al., Seal Team Six, Destiny’s Child) or at the very least have an underlying culture that joins them. An actual culture, not just a list of corporate touchstones, that you can visibly see either with a dress code or behavior.
> When someone asks me to help them with some git thing and I notice that they don’t have git information in their shell prompt, that’s the first thing I tell them to do.
This sort of dogmatic thinking is insufferable. Suggesting things is fine, insisting your way of doing things is the best way is really annoying.
Not the author, but I make micro commits because it helps me backtrack my implementation decisions.
A lot of times I would look at a line of code thinking why I would write something like that and find the reasoning by git blaming that specific line or chunk of code.
In short, I do it to make up for my poor memory.
> I use git on the CLI 99.9% of the time. I never used a GUI for git and don’t see a reason to.
Nobody needs a gui for git or a text editor but using magit is like a superpower compared to the command line. It is probably the best piece of software i've ever used. you can even drop down to the command line git inside of it if you need. i don't understand why anyone would prefer the cli over it.
Exactly. My favorite is probably "r s" or rebase subset: it is much more intuitive to use than remembering the order of the refs you pass to `git rebase --onto X Y Z`, and this happens to be something I do a whole lot since I use dependent branches to create dependent PRs.
My second favorite is "c F" or instant fix up.
But magit is a plugin for a text editor. No text editor, no magit. And the difference between a TUI and a GUI is only gradual.
I'm not sure your point? I am advocating for magit/a text editor plugin. git itself is not a TUI either like say lazygit is one. if someone were to rip out everything except magit and throw it into a TUI I'd be down to use it but as it is I only use emacs for magit because magit is just that good.
And you don’t need to a make three dozen shell/git aliases. The keybinds are already good.
GitKraken is amazing.
gitkraken is nice yeah. it's nowhere near the efficiency of magit imo. git is like ed. magit is like vim. gitkraken is more like maybe word? does everything you want has a nice clickable gui but it is not quite as efficient to use.
> I use git on the CLI 99.9% of the time. I never used a GUI for git and don’t see a reason to.
Because it shows more information about the state and spares you the trouble of navigating much of the zoo that is git cli design
For example,
> It shows the current branch and whether the repository is dirty, i.e. whether it has uncommitted changes
And the GUI would also show what/where those changes are and allow jumping to edit them. And you'd get updates after you edit even without manually refreshing the prompt
> spares you the trouble of navigating much of the zoo that is git cli design
Yeah. I understand the inner workings of git and am perfectly capable of using git on the command line but the git cli is just so horribly designed. I regularly have to google how to perform rather basic actions because the cli just isn't structured in any sensible way.
> When someone asks me to help them with some git thing
I point them at jujutsu (jj) and then they simply get on with using source control without the need for 8,000+ articles about navigating the insane Git command line interface.
Good article. I'm both using git in CLI and graphic tools. But atm the thing that GUIs have and none of the cli is the navigable git graph. And I do like seeing the graph.
I also love clicking on the current branch name, seeing all available branches and the checkout in an instant. 0 typing.
Or select files by intuitively pressing + on them (or their folder), go through all the changes on the side.
From these threads it seems that I'm the only one who appreciates some UX and not having to type literally everything every time I've got to do something on a computer.
Well, it's not navigable, but there is git log --graph --oneline --decorate
A lovely write up.
Regarding the formatting of commit messages: if everyone on your team is doing things slightly differently is something going wrong and what could fix it?
Is it a respect issue: people don’t follow a consensus because everyone is a headstrong individualist who refuses to play along with others?
Is it a communication problem? Are people just not intermingling in the commit message culture enough that they all naturally converge on a house style?
Is it a leadership issue? Are there no clear leaders in your engineering team who collude — consciously or subconsciously — to set the tone for everyone else?
Is it a technical issue? Without a pro-forma commit message template or additional tooling, are you failing your eng org by not giving them the framework / training wheels / guard rails they need to align on a house style for technical documentation?
I’ve been part of very healthy teams who largely ended up self organising into a consistent house style with a little help from tooling. I’ve also been part of unhealthy teams who fork themselves into multiple internal cliques that don’t intermingle enough to build up a monoculture. The healthiness of the teams might correlate with the commit message / commit graph style, or it might not. I wonder how it could be done better.
Specifically the commit formatting? How to write and markup?
A lot of people don’t care enough. Likely someone will be on your team. And if they all care then it might still be the case that they won’t have a house style. Because it’s still well-written and legible.
Yeah, commit message formatting as a proxy metric for how closely aligned your engineers are. Another one might be “do they all dress kind of the same?”
Lots of successful teams literally dress identically (Real Madrid, Biles et al., Seal Team Six, Destiny’s Child) or at the very least have an underlying culture that joins them. An actual culture, not just a list of corporate touchstones, that you can visibly see either with a dress code or behavior.
Mostly agree, though I prefer pulling latest from main over rebasing as the latter messes up the “New changes” markers for reviewers in GH.
Also we always squash merge so I don’t bother squashing my commits. Don’t review commit by commit.
> When someone asks me to help them with some git thing and I notice that they don’t have git information in their shell prompt, that’s the first thing I tell them to do.
This sort of dogmatic thinking is insufferable. Suggesting things is fine, insisting your way of doing things is the best way is really annoying.
When I see that someone is using the Git CLI exclusively and not magit/lazygit/… ;)
Why do you read "tell" as insisting instead of suggesting?
pretty_git_log() looks great, but using kitty on macOS it gives me this:
pretty_git_log column: line too long * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * |\ | * | * | * | * | * | * * | * | |/ * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > |\ | | * | * * |
Perhaps my commit messages are too long.
All of those characters are part of the ASCII history graph -- that repo must have a very interesting graph at some point!
Thanks for the writeup, I especially liked the Committing section.
Question for the author: when working alone on a personal project, what's the benefit of pushing every (minor) commit you've made?
Not the author, but I make micro commits because it helps me backtrack my implementation decisions. A lot of times I would look at a line of code thinking why I would write something like that and find the reasoning by git blaming that specific line or chunk of code. In short, I do it to make up for my poor memory.