Hacker News Reader

Comment by kmarc | Hacker News Reader

I am the same.

After the pandemic started and I had to witness over screen share how colleagues "use" (fight) git with all sorts of GUI tools, I had to realize that no GUI can be good enough while one doesn't understand git, or, even worse, it can be contraproductive, because people using these GUIs _think_ they understand, but they don't.

I even ended up creating a (tailored) 2x90min git course...

All that said, I heard magit praised so many times, I still have some hope that it's really as good as its reputation.

(Tried fugitive, which is the vim-world's answer to magit, even learned it properly but realized I always juzt <C-z> to the terminal and do stuff with the cli)

View on HN

Why would I use magit over the git CLI?

1. Discoverability. It'll display the contextually relevant options and commands at most points. By using magit, you're learning the git CLI commands at the same time, including commands that you'd normally never come across without a comprehensive read of the manual or release notes.

2. Fewer keypresses. Also, extra shortcuts for some common operations.

3. The bits that CLIs aren't very good for: staging and unstaging pieces of files, viewing conflicts.

(I do still use the Git CLI a lot of the time too.)

1 is really true. Magit is how I learned about workstrees!

I think (2) is why I use it, it's just much faster. It doesn't let you skip over understanding Git, it just makes you work faster.

I also think that the experiences of:

* looking into a stash and applying only selected changes from it, * browsing all your changes and staging only some of them, * quickly killing changes that you simply want to drop, e.g. not commit and remove from your edits

are much slower when using the command line.

I tend to avoid using stash in that fine grained way because branches are cheap in git, and you get a rich set of operations using a local branch to stack up unorganized code changes. Rely on stash on only very quick setting aside of work then returning to it. If I stash and find it needs to live longer than that - I’ll stuff it into a named branch.

Sounds like the same for which I started using (and then eventually abandoned) fugitive.

Staging part of files is the only thing I found hard with cli but then fugitive or simply git difftool helps with that too (using vimdiff)

For everything else I defined my own git aliases (git graph, git mr, etc)

Re: 3 ... I find that the CLI ("git add -p") works here when the scale of the changes I've already carried out is fairly small and there are not too many orthogonal changes in the file tree that I want/need to commit separately. If that happens, it's off to magit I go.

I'm usually a pro-GUI person but I've always found git GUIs to be confusing/trying to paper over the model in a way that made me not like them. Though I don't mind what IntelliJ has. Maybe I need to give this magit tool a try as well.

Magit is absolutely fantastic and it reduces friction, discoverability and joy. rebasing is easy. commiting is easy. staging is easy. discovering is easy. everything is easy. it's incredibly powerful and also incredibly easy to use. it's simply the best software i've seen written in a long time.

sounds like hyperbole but it's not.

edit: magit is like if you spent months crafting a bunch of aliases for the command line and then made a nice little menu of all of them and committed that to memory but also has it as a popup. and even then magit is an order of magnitude better... handily so.

I gained a better understanding of git through this document:

https://eagain.net/articles/git-for-computer-scientists/

I'm not a computer scientist and I think it's understandable. Everything became a lot more clear in my mind once I understood the inner workings.

That's a really cool article. The wording could be a lot simpler but the important part is that it does not abstract the concepts. They don't need to be abstracted because they are really simple. Situations can become very complex, especially when someone does not know what they are doing. Developers need to learn the priciples without lies and overzealous simplifications. If you know what's going on it's a lot more doable to not end up in a super complex situation, but not a lot of people have a really good explanation of git even if they understand it very well themselves.

The underlying model of git is not too hard to understand, and is actually pretty elegant. There are a number of good explanations online, including the one you linked.

The git tool itself, though, often operates at a much higher level of abstraction. I think that's more where the reputation of being hard to learn comes from. For instance, you'd probably need to write a paragraph or two to explain what "git checkout <branch>" does in terms of the actual object store. Add to that that the CLI is poorly designed - many commands have misleading names, a given command will do completely different things depending on the flags, there's a lot of implicit / counterintuitive behavior, and so on. See https://stevelosh.com/blog/2013/04/git-koans/ for some funny examples.

This free book[1] is authoritative and explains Git very well IMHO.

https://git-scm.com/book/en/v2

Reply on news.ycombinator.com