run "git log" to grab the commit hash
The really challenging parts of git IMO are around maintaining branches. Merge vs rebase, squash or no squash, when to back-merge, etc.
The best thing to learn about git is what the safety nets are, what commands do destructive edits, vs what commands do things you can undo. Once you know how to recover from all the non-destructive commands, you never have to stress about them again!
The reflog is weird and confusing at first, but once you know it’s here and a little about how to use it, all of a sudden you realize it’s pretty hard to lose things, as long as you commit them.
The whole point of software engineering is to write software that makes our lives better. Why would "deal with it" be the right answer to the horrific mess that is the Git UI?
If someone is having trouble learning how to use a lathe, that doesn't mean lathes are a "horrific mess" and need to be reworked, it means that person needs to learn more about the tool they're using and how to use it.
The frontend can be a ui or a cli like this with a good explain command.
It is important though that the final git commands are shown, such that you can learn, and find more details on the internet when needed.
So learn, yes, but whilst avoiding many initial pitfalls.
However, a first year college student building something and putting it out in public is a great achievement and something to be condemned.
I assume you mean "not condemned" or "commended" possibly?
Gut will never allow you to modify the history pushed to a remote repository.
My standard work flow is that I have a branch for each change that I commit to without any form. I just use it to checkpoint myself. Yes I push those both as backup and to get CI to tell me things I broke while I keep working without having a full local build kill my machine from the load. At the end I squash, rebase and force push and then merge to master. In fact we only ever allow clean rebase "merges" to master, i.e. fast forwards.
I'm all for the consistency in commands in gut for newcomers. I absolutely recognize that not everyone can just learn a bunch of command sequences.
That said I do not "get" why people complain about git checkout to switch branches. Svn used that and so being compatible with that was important for adoption even if people today, that don't even know that svn ever existed, find it weird.
But crippling, no sorry basically removing, one of the awesomest feature of git is mind boggling. Not a space bar heater moment. Heck git even deals totally fine with someone having pulled the branch you force pushed. People might not, especially if they never experienced it, but git the piece of software does not break even if you do it.
You're starting from a foregone conclusion that both of the following are true:
1. everyone is familiar with Subversion's design
2. that particular design decision was a good one
They aren't, and it wasn't.
I'm not saying switch isn't better. I am saying checkout was not a bad choice at the time. Git changed a lot of things vs what people were used to. Keeping some familiarity is actually a good thing for adoption. For "finding yourself at home". That does not mean they couldn't have introduced switch right away of course but the rest is history as they say.
Also, I did reference SVN specifically but even they did not invent this interface and some people surely switched directly from CVS to git without the detour. Do I need to me tion RCS? And they even used the shorthand co instead ;)
So after all that said please do read the quotes around "get". I don't "get" why people complain about it. As in most people seem to do exactly what you just perpetuated as well: they completely ignore historical context and complain why something wasn't done ~20 years ago in a way that takes 2023 context into account.
Yeah right.
What you actually said is that you don't get why people complain about it.
> even they did not invent this interface
It doesn't matter who invented it. Bad is bad. That's my point.
> most people seem to [...] ignore historical context and complain why something wasn't done ~20 years ago
Historical context isn't completely irrelevant—if the question is how something came to be. People complaining aren't complaining about that, though. They're complaining that it's bad, no matter how it came to be. It's not wrong to do so, and it's weird to say you don't get why they would. "Because it's bad" is why. That's sufficient enough to have a complaint, and anything else is irrelevant.
We may have experienced different complaints. What I hear is complaints like "Why on earth would you ever make switching to a branch be `git checkout`, that makes no sense?".
Queue historical context: Well very easy. In historical context, that would have been intuitive for people that would be using a version control system like git, because they were used to using tools that did the exact same thing.
Same way as a 20 something that has never used anything but git would not "get" why I say: "What's wrong with just using checkout? I've used that for years and years and it's second nature, why would you make me memorize a different way now? Also tell me, why can't I switch other things than branches with git switch, like a tag?"
It's like ChatGPT hype. I totally don't "get" it. If you believe the hype, we're all out of work yesterday. But it's actual capabilities seem to be far more limited and while useful for certain things and able to speed up development time if used right, it does not live up to the hype. Now of course you will correctly point out that not everyone is saying that and you are right. Just like not everyone complains about git checkout like I mentioned. But they exist and if not the majority they're the loudest.
edit:
I’ve actually seen the opposite where people dive into the details and kind of get lost, give up and end up with a fragmented mental model that leaves them afraid to touch it.
I think what programming (outside of even CS and CE) is lacking is an apprenticeship structure that starts on your first day on the job. That's all to say theory and practical application are always different but especially different in industry.
I'd love a command pallet where you could search for basic behavior in plain text like "reset my branch to GitHub's copy" or "only rebase two commits" and have it find the magic incantation.
It kinda needs separate command that shows you both reflog entries and commands that lead to it. Maybe merged with undo command so you could look at the history of operations, go back to that point, and get alert if you skip something already pushed upstream.
git rebase -i is essentially "undo" of sort but, uh, not a tool for faint hearts.
> git blame (git author)
I doubt people are confused by that
> I'd love a command pallet where you could search for basic behavior in plain text like "reset my branch to GitHub's copy" or "only rebase two commits" and have it find the magic incantation.
"git do" that just asks ChatGPT and pastes solution lmao.
- not just update `origin/branch` - not checkout `branch` and sync it with `origin/brach`
and it drives me crazy.
git config --global alias.chpull '!f() { git checkout "$1" && git pull; }; f'It's just so good. I don't know what I'd do without it.
Oh my god, I just realized this is ref-log (a log of references), and not re-flog (I'm not even sure what "to flog" is). No wonder I've never really understood why it's called that, I simply realized that I can look up older references to everything there by using it. Thank you!
Knowing the git enough to not need crutches is opposite of luddite.
But yeah, for devs sure, just read git book 2 or 3 times and if you're competent developer you'd probably get it just fine, once you get the concepts it's perfectly logical.
Just that not everyone is a developer wanting to use git for dev things and those UIs have place for that. I kinda wish there was more on the graphics side, like you can tell git how to diff binary files or even encrypted files but good luck explaining that to the non-coder trying to use it.
I still don't get developers complaining about it, it's your fucking main tool to work and about 10x easier than competence in any programming language, just learn it, you will use it longer than any piece of code you ever wrote most likely.
Suffice to say the complaints about git are alien to me. It seems that either devs need to know very little or everything to be safe. The middle ground falls under "knows enough to be dangerous"; you start getting over confident all fancy with your git moves and screw up. But nothing that can't be fixed.
That got me thinking about the first time I really screwed something up and had to figure out how to use git rebase, and the first time I tried to create a git submodule (back when submodules were new and there wasn't much help to be found on StackOverflow). I must have let the Stockholm syndrome set in, because the "explain" feature is a wonderful idea for students.
The dead-simplicity of it is very desirable in certain spaces. Back when I was in college, I wrote code for some indie visual novel games, and I was always the only person with a software development background. If I had a tool like this, it would have been MUCH easier for my colleagues to cooperate with me in the development process.