Hacker News Reader

Comment by sweezyjeezy | Hacker News Reader

I actually think git is a bad example of "just memorise these commands" - unless you are working with projects with a small number of users / branches - or you're fine to just delete and reclone if things get really hairy. I think a lot of my struggles with git came down to not grokking what it was actually DOING at first. Examples:

- not understanding branch pointers / staging / committing corrently. E.g. [add file] [modify file again] [commit] - what just happened? (IMO these things could have been named better). Also reset vs revert vs restore - easier to use these if you've internalised branch pointers etc

- git pull fails because it says it would overwrite a file you've never heard of - how is that file on your local? Is it ok to delete it?

- times when you (or your colleagues) need to rewrite history (rebase / squashing etc) - require a pretty good mental model of what is going on to both diagnose issues and to fix them

View on HN

The thing is, for me, I have never really struggled with anything. I work on a large project and use rebase, force push, amend and cherry-pick sometimes. I am fully confident that I can get myself out of any bind that myself or others have created just using my ~10 commands and without deep understanding of git internals.

I agree with rebase on shared branches however, that requires coordination and understanding of everyone using the branch. Sometimes, long running shared branches are needed but it generally something to try to avoid.

If you work at a place that doesn't care about a curated history, which I always have, it becomes much simpler.

It’s more accurate too. Linear rebased histories aren’t representative of what occurred.

I think much of the confusion comes from git log which is a lie. People want git log to be an accurate representation of what occurred.

A curated sequence of logical commits assembled into an idealized history is often much easier to review than the real history. However, to rewrite history well enough for that you need....

* a solid understanding of interactive rebasing, including `fixup` and `reword`.

* `git add -p` for adding partial sections of files

* `git commit --amend` for patching the last commit

* `git commit --fixup [COMMIT_ID]` for attaching patches to commits further back in history.

* `git stash` for pausing progress while you fix up an old commit.

* `git rebase -i --autosquash [COMMIT_ID]~` to apply the fixups

* topic branches that never get too big or drift too far from the mainline, because rebasing often becomes infeasible when repo snapshots are too far apart.

* A low enough error rate that you don't screw everything up when rewriting history (which is a reasonable critique and argument for why you shouldn't attempt this in the first place).

I can usually manage this, and efficiently enough that it's worthwhile — and my colleagues appreciate that my PRs are easy to follow. But as a reviewer, I don't insist on other people putting in the same investment.

It depends a lot on what you are doing. If making incremental changes to a production system, just try to use trunk based development style (except use pull requests - let's not be insane) along with targeted commits.

If you need to do exploratory work and need to share that with someone else, yeah, you will have lots of noise in these commits. Yes, maybe some of those commits wont even build depending on how long your build takes. One approach is to do a "clean room" style re-write with better quality commits (ideal) or likely some rebasing and cherry-picking might be needed - both of which are better than merging all of the noise to the repo.

Taken to the extreme, one could consider every character typed to be what "really happened" but of course no one wants that.

I've worked in more than one place where a 'clean history' was deemed so valuable that someone and re-applied all the deltas after the fact to create some kind of alternative timeline where everything landed just so, and we all had to eat the resulting force pushes to main

clean history and forced pushes to main are orthogonal. why were dirty commits making it to main the first place?

Single squashed commits with a linear history.

This scales for monorepos with thousands of engineers, too.

Every explanation of git I have seen starts by explaining that git is cool because branches are just pointers and then talks about the index/staging area. If you don't understand that then you aren't going to be writing code worth committing anyway, are you? A software developer that doesn't understand reference semantics?

> Every explanation of git I have seen starts by explaining that git is cool because branches are just pointers and then talks about the index/staging area.

Which is precisely _not_ a "just memorise these commands" approach to git right?

Also re: your general snark - try a bit more empathy? I'm sure you are an experienced dev but we are talking about people LEARNING git, they don't have the same points of reference as you do today.

I learnt git too. I was new to it too. It used whatever the information is that is on the official git website and had no problems. And that was back when its interface had quite a few rough edges that have been sanded down

Today there is "git switch" which people say is good for beginners. I have too much git checkout muscle memory.

Reply on news.ycombinator.com