Hacker News Reader

Comment by expazl | Hacker News Reader

It reads a bit like the author has a misconception of what commmits are. A commit is not a diff, it's a snapshot. All of the talk about branches containing changes etc, make sense in the context of it being a reference to the latest snapshot. And yes it might not make sense if you think of a branch as a reference to the latest difference, but this is a misconception.

View on HN

The author has written more about git (see the link at the bottom) than there is in the git manual. Do they… do they know there’s a manual?

When you say "a snapshot", are you meaning "a snapshot of the complete file/folder tree at the point in time of the commit"?

While that's true from a mental perspective, the on-disk format of most standard commits is indeed a diff.

eg what changed from the previous commit, as output by the diff command

While it’s true that the packed format does only store some information - it is never a diff file and always pointers to trees and blobs.

I assume you’re referring to packfiles[1], but those are (a) very much an implementation detail (they exist only to save disk space and appear basically nowhere in the git UI), and (b) not diffs—git will pack together whatever blobs its heuristics[2] think “look similar” with no regard for whether they’re actually related to each other, as long as they seem likely to gzip well together.

[1] https://git-scm.com/book/en/v2/Git-Internals-Packfiles

[2] https://github.com/git/git/blob/master/Documentation/technic...

Came here to say this. Commits on a branch should be as easy as "save file". You shouldn't put commit messages on them other than something like "snapshot 3". Nobody cares about the commits on the branch.

That sounds weird to me, as commit messages in a (side?) branch are just as useful as commits on the main development branch. eg very, as they describe what that change did

Maybe the only time / scenario I'd agree with you though, is when I'm just creating a commit to capture a temporary development state (eg WIP) on the way to some development objective. That's not very often though.

For certain changes, a clean branch history can be very valuable during review. For example, if you had some feature which was rolled back due to bugs, a new branch with the feature plus the fixes should have the original (buggy) feature as the first commit(s) with no other modifications so that people can clearly see what was done to fix the original bugs and what was in the original code.

However, you can fix things up when ready for review by just rebasing things into a coherent sequence of commits. I really wish there was a good autocommit/push feature in Git that would help back things up but continuously rebase and compact old autocommits.

It's true. Making a very clean git commit history is key to making the most use of git. That's partly in choosing sizes of commits (does one thing, not two things), partly in choosing good commit messages, and partly in branching strategy.

Personally I try to avoid merges at all costs. Instead, I always try to keep feature branches cleanly rebased off master. This sucks with github, so I have a tendency to destroy and recreate feature branches to avoid getting merge commits mixed up in the remote. GitHub is dumb like that. I don't really know how to fix that except to suggest that some branches on remote should be auto-rebased if it can be done cleanly. But it's still a pain.

Reply on news.ycombinator.com