I recommend this site to people a lot, it's nice. What's not nice is people not being aware that Git comes with a graphical history viewer for your actual repositories, gitk, which should really be people's default go-to. (There's also log --graph if you want ASCII art, but an actual GUI is quite a bit better. There's also other GUIs that display the information gitk does, of course.)
Git is truly the Dark Souls of version control systems - that is, it's wonderful and masterfully crafted but it has attracted this misguided cult following which spreads misinformation about how intractable and hardcore it supposedly is. Dark Souls doesn't have forge sites deliberately (?) adding to the confusion (maybe all those youtubers...), though.
Try also "tig" which is something in between git --log and gitk.
Also, I firmly believe that git is very simple if you use it right. I'd you are deep in the manual with exotic commands and flags it's most likely your own fault.
Edit: forgot to add that saying git is not complicated always gets heavily downvoted on HN. So goodbye digital karma...
Git's data model might be simple, but the commands sure aren't. Compared to Mercurial the UI is a mess, although better than it used to be, which isn't surprising since each command initially kind of evolved as a separate program rather than being designed as part of a coherent user experience like Mercurial.
I find that Git can usually do everything Mercurial can, but it does involve those "exotic commands and flags". For example, the equivalent to
hg id -i
is apparently
git describe --abbrev=12 --dirty=+ --always
which is not exactly obvious, not even if you read the manual. Stack Overflow also suggests alternatives[1] using "git log", "git status" and "git rev-parse" which do similar but slightly different things and accept similar but slightly different options.
What about listing all filenames from all commits – "hg manifest --all"? I'm sure it can be done, but I'm equally sure it involves exotic flags.
That's kind of a misleading comparison. It takes that many characters to exactly reproduce the "hg id -i" behavior because hg chose a certain set of defaults that git didn't happen to choose. What if as an hg user I want the first 16 chars of the commit ID and don't want the "dirty +"? The hg command quickly starts to look uglier.
If you just want the current commit ID in git it's just "git rev-parse HEAD". Which is still longer and uglier than "hg id -i", yeah, but it's a fairer comparison.
True. My point is that Mercurial has a more coherent set of commands that usually, in my experience, give you an obvious way to do obvious things.
Git has (although it's gotten better!) functionality spread haphazardly across different commands, and many commands can perform several seemingly unrelated tasks depending on the flags. There are lots of command to give you the hash of current commit, all with different combinations of bonus features, and in this particular case we use describe (which really seems to be for finding tags reachable from particular commits) because it happens to support the right combination of features.
(Perhaps I should mention that I'm currently migrating to Git. Git is fine. Many things are better than in Mercurial, just not the UI.)
TBH I'm not sure I'd ever heard of "describe" -- I'd always used rev-parse to get a commit ID. But now that I'm trying it, it gives me a branch/tag name rather than a commit ID (either bare "git describe" or with the other arguments mentioned above). So...not really sure?
It is simple and powerfull but not intuitive. I work a lot with biologist and I explain it as a lab journal: for a lab journal there are, depending on your company, many strict rules to follow, to keep it "valid". For example, changes need a date stamp, people need to sign off on your journal every 3 months. You need to number the pages and keep an index to show it has not been tampered with, etc.
Like many things in the computer world one starts out feeling that something is overly complex and then slowly one realizes that one would have designed a system just like it is now, given the opportunity. Realizing this has made me stop judging new tech until I try it for some time. Also, when many people use something and I find it to be overly complex, I try to reserve judgement and spends some hours at least to really try something. Although this does require some problem to be solved (a concrete target), at least for me.
The best way I found to learn git is to read the first 3 chapters of Pro Git. Yes it's a pain, yes you're going to have to sit through the "distributed source control" speech again, but the enlightenment of realising why it works like it does is great.
When you realise it's nothing more than commits and a bunch of special labels it starts to make sense.
EDIT: Meant to add that sites like ohshitgit might help in a crisis but you're only a few hours reading off working out WHY those things work.
> Git comes with a graphical history viewer for your actual repositories, gitk
Well, sometimes it does, sometimes it doesn't, e.g. on macos it doesn't.
> gitk, which should really be people's default go-to
That's a matter of preference. For instance, I've been recommending Magit to all new starters (quickly installing spacemacs as a shell for that) and it's been working out great so far.
See, there's literally thousands of "git guides" and maybe dozen of "visual guides" (not to mention cheatsheets, "handy aliases" lists, etc.) and they keep coming, which begs the question — why are they there in first place? How come existing ones are not enough?
> Git is truly the Dark Souls of version control systems
Yeah, but in a bad way. In my 10-years-experience with DVCS, Git requires orders of magnitude more attention than any other (D)VCS (except, maybe, monotone), offering nothing in return.
> Git is truly the Dark Souls of version control systems - that is, it's wonderful and masterfully crafted but it has attracted this misguided cult following which spreads misinformation about how intractable and hardcore it supposedly is
To be fair, From Software definitely plays into the "hardcore" image of Dark Souls with their marketing.
Do you think we'll ever get "Git: Prepare to Die Edition"?
Git is truly the Dark Souls of version control systems - that is, it's wonderful and masterfully crafted but it has attracted this misguided cult following which spreads misinformation about how intractable and hardcore it supposedly is. Dark Souls doesn't have forge sites deliberately (?) adding to the confusion (maybe all those youtubers...), though.