Hacker News Reader

Comment by shikoba | Hacker News Reader

> It's when you move a file and make substantial edits that it gets confused.

It's your POV that it's the same file. One could argue that it's a new file and the content of the old one embed in the file. That's the huge problem with git users, people cling desperately to the idea of changes, when git is just about snapshots.

View on HN

People "cling desperately" to the way they are actually working. That Git uses an alien model that happens to somewhat match what I'm doing doesn't mean I'm "desperately clinging" to the actual reality of what I'm doing (editing a file).

So if someone creates a new file and integrate the content of the old file to reach the same folder state than yours, you think s/he does something different?

Yes? Editing a file is different from creating a new file with some code copied from somewhere else, obviously. They may reach the same end state, but that doesn't make them the same operation.

It also happens that one is much, much more common in software development than the other, so it's a much better mental model of what SEs do.

> They may reach the same end state, but that doesn't make them the same operation.

So you're clinging to your mental model. Thanks for proving my point.

This is how work is actually done, and my mental model matches how I and my colleagues and yours as well actually work.

I could contort my mental model to make it match how Git works, but it is a contortion that some tool imposes on me.

We work in computing, I would expect everyone's mental models to be computational, not equational - different algorithms with the same result are still different. QuickSort is not the same as Merge sort just because they have the same inputs and outputs.

The issue is that the path you used to go from A to B is yours, one could use a totally different path. But what really matters is that your product is now in state B. That's what you ship, not the path.

Git has both concepts, snapshots and changes. You'd have to contort yourself more than a bit to describe common uses of "git rebase" without viewing it as changes, for instance.

You may be aluding to git's underlying storage being snapshot based, but it actually also has diffs in pack files.

> but it actually also has diffs in pack files

Storage optimization, absolutely unrelated to the diff between two snapshots.

The semantic layer uses both, and the implementation layer uses both. Saying that it's one or the other just seems misguided.

I don't understand your point. Mine was just that git could decide to store only snapshots, it would change nothing except for low level commands that deal directly with objects storage.

Reply on news.ycombinator.com