3 ms·

> He says “a lot of developers have not learned git IN DEPTH” and you respond by saying that’s not true because you’ve gotten away with just using a small subse

> He says “a lot of developers have not learned git IN DEPTH” and you respond by saying that’s not true because you’ve gotten away with just using a small subset You forgot the “because it's actually kind of terrible from a UX standpoint”. My stance is against that. I haven’t learned git in depth because I never knew any other workflow than code and check in the changes. There’s not a lot of guides on how version control can help in the software development process. It wasn’t until I got involved into OSS that I learned more which in turns give me the motivation to use and learn about git in depth. I’m also using magit (after a tour in various GUI) but for me it is to git what vi is to ex. Direct interaction instead of a command prompt.

saghm 1mo ago
> I’m also using magit (after a tour in various GUI) but for me it is to git what vi is to ex. Direct interaction instead of a command prompt. I'm not sure I understand how "I use a specific text editor with a specialized interface into git that's superior" is a counterargument to the first-party tool having horrible UX. That seems basically the exact same as what I was saying about jj, except via emacs instead of a CLI. Either way, we've opted out of the actual experience of the tool in favor of using an alternative tool that operates on the version control.
- skydhash 1mo ago
  Magit doesn’t anything that is not readily available in git. Most of magit usefulness comes from “active objects” (meaning you can act directly on the report of some commands like git-log) and quick command construction due to transient and autocompletion. It requires the same mental model as git.