[wakawaka28]

Lol if you can remember how to use ImageMagick and Ffmpeg but not Git, I don't get it. Those programs do have very different argument passing styles than Git, but Git uses the same style as most every other unix/linux program. If you use it and know what you're doing, you should not be able to lose any work.

My advice to get over the hump you're on is to commit more often, check the status more often (`git diff [--staged]` and `git status`), and make sure you're branching or tagging enough to not lose commits. Then work on how to edit commits with `git rebase -i`. You can use rebase and cherry-pick to eliminate any unwanted commits or branches easily (notwithstanding conflicts, which are another critical thing to learn). If you feel like you messed up, you can almost always `git reset --hard` to the last commit you were on. If you forgot which commit you were on, there's the reflog. Generally, to be good at Git you have to take a few hours to learn it. It differs from the other programs you mentioned because there are different problems you can encounter at various points while using Git, whereas those other ones just succeed or fail and don't usually fail in unrecoverable ways (you just run them again until you're satisfied with the output). You can iterate on modifications to your commit history with Git but that is trickier and riskier.

There are many excellent Git tutorials online that explain everything an ordinary user needs, including rebases and the reflog. I think Github has one. Maybe that's what you need to figure it out, in addition to practice of course.

[wruza]

What ffmpeg and magick have in common that git doesn’t is (relatively) intuitive and straightforward arguments. They have lots of arguments, but they are otherwise simple and consistent. If I remember an idea, it always works the same and looks the same.

In git there’s always “foo”, “bar --frob” or “baz :QUUX -j” in a set of logically related operations, and neither of keywords make sense. Also every generation of git had its own ui ways, so it’s very hard to learn if it’s e.g. some reset/checkout incantation or just restore that you wanted, because when you refer to google, it never knows it’s not 2015 anymore. Some humans can’t learn inconsistent badly named things, I’m one of them. I can remember, but to actually understand I’d have to understand Linuses mind’s inner machinery, which is alien to me.

[wakawaka28]

Idk which common Git commands you think are so incomprehensible or unstable between versions. Structure-wise, there's a combination of positional and non-positional arguments, but that's not uncommon on Linux. I haven't seen a major change in the way the Git UI works for the basics in the past decade, that I can recall. Of course Googling an answer to a problem can lead you off the beaten path, but I think that if you get an idea of what looks appropriate you won't be taken in by hairbrained approaches.

I think most of what you need is actually on this cheat sheet, so maybe all you needed was a reference.

[CRConrad]

> you won't be taken in by hairbrained approaches.

Hare-brained. (Hares are not supposed to be very smart animals.)

[wruza]

Looking at subj cheatsheet, I immediately see `git add .` described as adding ALL untracked files and unstaged changes. But deleted files will not be included, unless you pass -A / --all. But wait, that's just my memories, since git now does include removed files, according to my tests today and https://git-scm.com/docs/git-add#Documentation/git-add.txt--.... It's hard to tell if that changed in the past decade or not, cause the manual never mentions neither a version not that -A is default now in a section corresponding to -A. I still have -A in my bash aliases and it was 2017 when I finally got frustrated enough to create them.

And this complexity was literally from the first trivial thing I checked, I wasn't looking for it for hours to gaslight anyone here. Git is nice and fast as a core program, but its ui, documentation, compat and informational ecosystem are just poor.

[CRConrad]

What do you mean, "deleted files" -- removed from the git staging area with "git rm", or actually deleted on the file-system level? (I don't think it ever added the latter, did it?)