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 (lots of inconsistent naming of things and somewhat leaky abstractions), and that Mercurial faced an uphill battle in large part because it lacked compatibility with what people were already using. I haven't used Mercurial, but from what I've heard quite a lot of how jj does things is similar to Mercurial, just in a way that's compatible with git. I haven't used git directly for over a year in favor of using jj despite exclusively using git repositories, and no one I've worked with has even needed to be aware.
> 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.
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.
> 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.
> 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.
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.
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?
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).
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?
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.
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.
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.
"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.
As a Mercurial fanboy, git took off thanks to being from Linus, and a requirement to contribute to the Linux kernel, from there the adoption wind was in motion.
As someone who was a mercurial fanboy too, critical element was that Github happpened for git while mercurial had nothing comparable - and before anyone points at bitbucket, it fucking sucked in UX
It was huge problem for Git adoption, that's why I mentioned GitHub
EDIT: GitHub had probably the first UX where I actually liked what I got, compared to various earlier git based ones, or the horrible CVS and SVN ones where clicking on a file name definitely didn't do what you expected.
I barely remember Bitbucket from the mercurial era but I do recall that while it was better than some, it was still worse than GitHub, whose "here's default branch's HEAD, plus auto-opened and formatted README" was really a game changer
