4 ms·

> I'd argue that the reason a lot of developers have not learned git in depth is because it's actually kind of terrible from a UX standpoint Not really. I reme

> I'd argue that the reason a lot of developers have not learned git in depth is because it's actually kind of terrible from a UX standpoint Not really. I remember my early years with git and the favt was that I never needed more than clone, add, commit, pull and push. While I’ve done some mistakes that got ne to learn more, especially with creating branches and undoing. I’ve never needed a lot, even when I started using GUI which exposed more concepts. Why? Because I have no understanding of version management and how it’s useful in a dev workflow/release process. I was just using it for checking in work. Since then, I’ve read the “Pro Git” book, learned how devs and teams handle versioning and devel a good understanding of how git can help me in my coding process and general software development. And it’s very good at what it does.

stouset 1mo ago
I honestly kind of think your experience is in favor of the GP’s assessment.
- skydhash 1mo ago
  Not really. Learning the piano and learning music theory is two different things but tied together. One is skill and muscle memory, the other is theory and understanding. It’s the same with git and version control. One is a process and the other is a tool.
  - deleted 1mo ago
    [deleted]
  - saghm 1mo ago
    I don't think this framing makes much sense; playing piano isn't a "tool" that you use to achieve some other task, it's literally the goal itself. Using git is not the goal, it's the tool I use to do something else, and needing to learn the underlying theory of how a tool works that's only a small part of how I do my job is not a good user experience.
    - skydhash 1mo ago
      The goal is to produce music, and such music is generally constrained by music theory. Using git is to version control some software, and version control is dependent on the programmer/team workflow. At the team level, it’s guided by the release process, configuration management, which version is canonical. At the programmer level, it’s usually guided by how to switch between task, how easy to explore an idea and save the resulting experiment, how to reset the code to a know state and how to replay a previous changes on top of new changes. So you discern what you want to do (which is independent of the tool), the learn how to use git to do them. If you start from git, you’re going to be confused, just like someone opening autocad with no knowledge of engineering drawing.
pkulak 1mo ago
But what if you didn’t have to read a 400-page book to properly version control your software?
- inejge 1mo ago
  "Properly" is doing a lot of work here (Claude would say it's load-bearing ;) If one's needs are modest, then no, the 4-5 basic operations don't need a 400-page book to understand, and are quite proper for version-controlling one's software.
- skydhash 1mo ago
  I read many 400 pages books to learn various things about software development. So one more to learn about version control was worth it.
drob518 1mo ago
Yes, really. You just proved the other poster’s point. 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. Git is quite powerful, but the cli is a train wreck of complexity and inconsistency. Learning the options to one git command means you’ve learned the options to exactly one git command. No other git command is required to use the same terminology. Personally, I was stuck in “git basics land” (all the basic commands you list) until I adopted Magit in Emacs. IMO, the Magit team deserves a medal for making git usable at an advanced level. I don’t have an opinion about jj yet, but no one can hold up git as a pinnacle of great source control. Yes, it’s powerful, but it’s a UI train wreck.
- skydhash 1mo ago
  > 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.
    - 1mo ago
saghm 1mo ago
Can you give me a a terse summary of what "checkout" means that doesn't involve needing to either list or ignore several very different types operations?
- skydhash 1mo ago
  I would say “align the worktree (or part of it) to a specific state previously saved in the repository.” The repository is a store, you check out the previously saved instance of a file, a group of files, or a subtree. In that regards, switching branches and restoring files is actually the same thing. A commit stores whole files and branches are pointers to commits (which update themeselves).
  - saghm 1mo ago
    That sounds like an incredibly leaky abstraction to me, and pretty much exactly what I meant by the UX not being very good.
    - skydhash 1mo ago
      What is version control to you? For me it’s basically being able to store and retrieve snapshots of code at different instances of time, where each instance has its own significance. Checkout have a very precise meaning in that regards, just like add and commit. Maybe you can explain how is it leaky based on your understanding of version control?

stouset 1mo ago

I honestly kind of think your experience is in favor of the GP’s assessment.

skydhash 1mo ago
Not really. Learning the piano and learning music theory is two different things but tied together. One is skill and muscle memory, the other is theory and understanding. It’s the same with git and version control. One is a process and the other is a tool.
- deleted 1mo ago
  [deleted]
- saghm 1mo ago
  I don't think this framing makes much sense; playing piano isn't a "tool" that you use to achieve some other task, it's literally the goal itself. Using git is not the goal, it's the tool I use to do something else, and needing to learn the underlying theory of how a tool works that's only a small part of how I do my job is not a good user experience.
  - skydhash 1mo ago
    The goal is to produce music, and such music is generally constrained by music theory. Using git is to version control some software, and version control is dependent on the programmer/team workflow. At the team level, it’s guided by the release process, configuration management, which version is canonical. At the programmer level, it’s usually guided by how to switch between task, how easy to explore an idea and save the resulting experiment, how to reset the code to a know state and how to replay a previous changes on top of new changes. So you discern what you want to do (which is independent of the tool), the learn how to use git to do them. If you start from git, you’re going to be confused, just like someone opening autocad with no knowledge of engineering drawing.

pkulak 1mo ago

But what if you didn’t have to read a 400-page book to properly version control your software?

inejge 1mo ago
"Properly" is doing a lot of work here (Claude would say it's load-bearing ;) If one's needs are modest, then no, the 4-5 basic operations don't need a 400-page book to understand, and are quite proper for version-controlling one's software.
skydhash 1mo ago
I read many 400 pages books to learn various things about software development. So one more to learn about version control was worth it.

drob518 1mo ago

Yes, really. You just proved the other poster’s point. 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. Git is quite powerful, but the cli is a train wreck of complexity and inconsistency. Learning the options to one git command means you’ve learned the options to exactly one git command. No other git command is required to use the same terminology. Personally, I was stuck in “git basics land” (all the basic commands you list) until I adopted Magit in Emacs. IMO, the Magit team deserves a medal for making git usable at an advanced level. I don’t have an opinion about jj yet, but no one can hold up git as a pinnacle of great source control. Yes, it’s powerful, but it’s a UI train wreck.

skydhash 1mo ago
> 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.
  - 1mo ago

saghm 1mo ago

Can you give me a a terse summary of what "checkout" means that doesn't involve needing to either list or ignore several very different types operations?

skydhash 1mo ago
I would say “align the worktree (or part of it) to a specific state previously saved in the repository.” The repository is a store, you check out the previously saved instance of a file, a group of files, or a subtree. In that regards, switching branches and restoring files is actually the same thing. A commit stores whole files and branches are pointers to commits (which update themeselves).
- saghm 1mo ago
  That sounds like an incredibly leaky abstraction to me, and pretty much exactly what I meant by the UX not being very good.
  - skydhash 1mo ago
    What is version control to you? For me it’s basically being able to store and retrieve snapshots of code at different instances of time, where each instance has its own significance. Checkout have a very precise meaning in that regards, just like add and commit. Maybe you can explain how is it leaky based on your understanding of version control?