6 ms·

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

by kmarc 5y ago

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)

matheusmoreira 5y ago
I gained a better understanding of git through this document: https://eagain.net/articles/git-for-computer-scientists/ 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.
- ThaJay 5y ago
  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.
- yissp 5y ago
  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/ https://stevelosh.com/blog/2013/04/git-koans/ for some funny examples.
- beermonster 5y ago
  This free book[1] is authoritative and explains Git very well IMHO. https://git-scm.com/book/en/v2 https://git-scm.com/book/en/v2
GlennS 5y ago
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.)
- jwr 5y ago
  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.
  - digikata 5y ago
    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.
  - deleted 5y ago
    [deleted]
- mplanchard 5y ago
  1 is really true. Magit is how I learned about workstrees!
- kmarc 5y ago
  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)
weaksauce 5y ago
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.

by kmarc 5y ago

matheusmoreira 5y ago

I gained a better understanding of git through this document: https://eagain.net/articles/git-for-computer-scientists/ 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.

ThaJay 5y ago
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.
yissp 5y ago
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/ https://stevelosh.com/blog/2013/04/git-koans/ for some funny examples.
beermonster 5y ago
This free book[1] is authoritative and explains Git very well IMHO. https://git-scm.com/book/en/v2 https://git-scm.com/book/en/v2

GlennS 5y ago

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.)

jwr 5y ago
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.
- digikata 5y ago
  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.
- deleted 5y ago
  [deleted]
mplanchard 5y ago
1 is really true. Magit is how I learned about workstrees!
kmarc 5y ago
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)

weaksauce 5y ago

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.