Hacker News Reader

Comment by ryukoposting | Hacker News Reader

Maybe it's just morning, or maybe I'm a luddite, or both, but my knee-jerk reaction to this was "why does anyone need this? Just learn git." But then I saw the "explain" command, and then I read that you're a new CS student.

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.

View on HN

I agree with the just learn git part.

However, a first year college student building something and putting it out in public is a great achievement and something to be condemned.

I'm sure this was a typo, but I don't think you meant "condemned." Maybe "commended"?

Refreshed before I commented to say this and saw your comment labelled "0 minutes ago". :)

Commended. Yes. Stupid autocomplete on the phone.

i laughed at seeing that above too - who knows? in other industries it's common to lay the crap on the new guy but haven't experienced that as much in software

> [...] great achievement and something to be condemned

I assume you mean "not condemned" or "commended" possibly?

There's also "condoned".

You remind me of my primary school teacher who had the tendency of condemning me for my achievements...

Great art is often unrecognised by people stuck in the rut of convention.

Also it forces you to never get rid of the training wheels it seems.

    Gut will never allow you to modify the history pushed to a remote repository.

Prompt me, sure. Disallow? WTF?

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.

Yes, and voiding even more use cases, total deal breaker, leave that to your or remote's githooks if you need it.

xkcd://1172

While that's funny it's the opposite of what this is ;)

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.

> I do not "get" why people complain about git checkout to switch branches. Svn used that

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 to begin with

They aren't, and it wasn't.

I don't think you understood what I was saying.

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.

> I am saying checkout was not a bad choice at the time.

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.

Now you removed my quotes from get. Tsk tsk :)

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.

I've never seen an xkcd URI scheme before. Huh.

edit:

https://nullroute.lt/misc/xkcd/

commended?

I agree. I think first year college students building things and releasing them to the public ought to face possible jail time.

Got requires a mental model. I've tried to teach git without the mental model and it just doesn't work. There's a whole pack of people on the internet who refuse to learn the internals and complain incessantly about it. I don't think there's anything wrong with them, but it's a signal that for some folks conceptualizing what's in the docs is difficult for them. The explain command I think could go a long way in doing that, similar to how I used explain to learn SQL.

Do you have a good guide to the mental model of git? I agree with you and I think that's what preventing me from getting more familiar with it.

They used to have a page that summarized it all, but now there's a book! https://git-scm.com/book/en/v2

I have a fuzzy jpg level understanding of the internals and I do completely fine with ~10 git commands.

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.

My rough mental model is each ref is like a .zip of your source code. Branches point to these. When you commit you create a new ref, it points to it’s parent and the branch now points to it.

To what extent should educators be responsible for teaching Git? I learned just enough to push to master for my assignments, and handle merge conflicts. Profs didn't care if you knew Git, they cared if you know how red-black trees work, or how CANBus works.

If by educators you mean professors I think none. Git is very specific and teaching the various different VCS paradigms wouldn't really be helpful in learning Git specifically. I say that in light of the fact that (at least in the US) a university is responsible for teaching students theory, and we've about maxed CS and CE out in theory.

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.

"just learn git" unpacks to two different things - gaining an understanding of the git model and how the various operations query and modify the repository state, and learning the arcane minutiae of git's command line invocations. the former is indeed a very valuable part of levelling up as a developer; the latter is only useful insofar as you have to interact with the `git` command line tool. it has no intrinsic worth, and if someone would rather write and use `gut` instead, more power to them!

I agree with the just learn git part. We are all students when it comes to learning something new to you and this career is a constant stream of learning things. So my advice would be to deeply learn what your tools are doing and do that by trying out different things in a zero risk sandbox. Git is decentralized, you can setup a local repository that you can use for practice and to learn what is going on.

Git and its particular interface aren't deep facets of the universe we need to get used to, building better tools and exploring new interfaces is exactly what we should be doing. Sure, learn Git, but that's not a reason to give up on alternatives.

> this career is a constant stream of learning things

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?

It's not really "deal with it" it's "learn the tool to start using it effectively".

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.

If using the tool effectively is burdensome enough, then it's the same as "dealing with it".

Well, yes, but "enough" is doing a lot of heavy lifting there. Learning git is a large and steep learning curve, but the benefits from doing so outweigh the costs.

Sure but if you can make a tool that saves you 5 minutes of time on a lathe every time you use it, you may be a fool for not doing it. That's the whole point of building tools.

In industry they use CNC millers, I guess many workers found lathes too unhandy and slow.

An alternative frontend to git cli is a good idea, since several git command names are very counter-intuitive. Git checkout to switch to a branch that you already have checked out, git add for adding new files, for marking resolved as well as for staging. Git status only shows your local status without looking at the server.

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.

In my case, a lot of the complexity of Git is in the edge cases. Like, I rarely if ever have to revert, but when I do, it's very stressful to remember everything to get it right. This will certainly eliminate that occasional, but monumental, stress.

The revert command is a good, easy solution- "git revert <commit-hash"

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.

That's what tig is for.

https://jonas.github.io/tig/

Revert is normally extremely safe, I’m curious why it’s ‘monumentally’ stressful?

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.

IMO git would be way better with different naming and some UX improvements. Like a git undo[1] command, or renaming git reflog (git usage or git cmdlog), git blame (git author), and so on. Also stuff like the index, while great for experienced developers, leads to a lot of confusion early on.

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.

[1]: https://blog.waleedkhan.name/git-undo/

> git reflog (git usage or git cmdlog)

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.

I've been using git for years and do `rebase -i` daily, bisect many spooky commands. However, I still don't know how I can update a branch and switch to it in one motion:

- not just update `origin/branch` - not checkout `branch` and sync it with `origin/brach`

and it drives me crazy.

Not aware of a built in way, but if you use bash or similar as your shell you can do an alias like

  git config --global alias.chpull '!f() { git checkout "$1" && git pull; }; f'

Didn't think about alias for this even though I have alias for many other things, that should prevent `direnv` from triggering between checkout and pull. Thanks.

Why is rebase such a reviled git command? It's so useful. Interactive rebase is essentially a centralized place for editing history: reordering, squashing, amending, rewording, dropping, merging, splitting. Pretty much anything anyone could ever want to do can be done with interactive rebase. Enable autostashing and explicit dropping of commits and there's basically no way to screw things up. In the event that does happen somehow, reflog shows previous heads and even notes the point where the rebase began, making it easy to hard reset.

It's just so good. I don't know what I'd do without it.

It's so easy to end up in rebase hell where you're constantly fixing the same diffs. If you know what you're doing and can get the rebased commits to be pretty small it's okay. Although I've recently started using merge commits again and just squashing my branch when I merge into main.

Rebase (with or without -i) is one of my most used git commands. The one thing I still get confused with is whether I have to commit to continue or not.

> git reflog (git usage or git cmdlog)

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!

To flog is to beat with a whip, so it might be both.

Or, trying to sell; "He was flogging his wares".

I agree with learn git, but learning git doesn't make git's CLI good. I would love a CLI equivalent of magit that I could recommend to people.

Have you heard of LazyGit? It's a Git TUI.

> Maybe it's just morning, or maybe I'm a luddite, or both, but my knee-jerk reaction to this was "why does anyone need this? Just learn git."

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.

I think in general, git is not a great tool for developers. If non-developers are required to use git, I think you may have a process problem. However, if that's the state of things, I think non-developers are probably better served by a GUI than a CLI command.

My first reaction was "git already has an easy to use CLI!" But reading a bit more of the post I definitely see how many things I don't think about anymore aren't as intuitive to a newcomer. And hats off to this student for making themselves a tool. (Probably ended up learning a lot about git in the process too.)

I work with approx 10 junior developers they use basic push/pull/commit/checkout/cherry-pick git, have no idea how it works, only what it does. Their training composed of looking at a wiki intro and some hand holding. In 10 years by far the biggest git related issue is quality of commit messages... (and maybe the commit content)

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.

Reply on news.ycombinator.com