3 ms·

Git stores snapshots and that’s it. The whole tree, not per-file. As to why Linus doesn’t like storing file moves: https://public-inbox.org/git/Pine.LNX.4.58.0

Git stores snapshots and that’s it. The whole tree, not per-file. As to why Linus doesn’t like storing file moves: https://public-inbox.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org/ https://public-inbox.org/git/Pine.LNX.4.58.0504150753440.721...

bqmjjx0kac 3y ago
Man, he communicates like a dick all the time I guess.
- keybored 3y ago
  He does argue in a borderline hysterical way on many occasions.
xorcist 3y ago
I'd be happy to argue why Linus is wrong here. Many things would be much easier if git recorded some more metadata in every commit: file moves, and branch moves, to start with. Having some sort of notion of "parent branch" would be very useful for a number of common operations, and a "renamed file" without having to rely on client dependent heuristics too. Empty files trip people up all the time so a "create file" would fit in perfectly. These concepts would also be a good basis for more user friendly clients. Other version control systems do this the surprise factor should be low.
- erik_seaberg 3y ago
  People would get lazy and rename a file without telling Subversion they had done it, so it would write a “old file deleted, new file created from nothing” revision. Most of the merge conflict resolution machinery just couldn’t run without the missing guidance. Git infers someone probably renamed a file you edited or vice versa, which seems risky but works better in practice.
ziyao_w 3y ago
It's kind of funny to see Linus browbeaten other people into submission regardless of him being right or not, while claiming "I am always right". A few counter points: - `hg` has `cp`, and I believe both Meta and Google's internal systems have that; - git has `mv`, which was added later, but it is really janky and git would forget files are moved which I think it is because git doesn't try to track that, likely because of the philosophy here; - as for storing file moves - nobody said you *have* to use this information, but you can certainly use this information to help with things. The whole thread is an interesting read though and I will try going through it someday - maybe doing that would change my mind.

bqmjjx0kac 3y ago

Man, he communicates like a dick all the time I guess.

keybored 3y ago
He does argue in a borderline hysterical way on many occasions.

xorcist 3y ago

I'd be happy to argue why Linus is wrong here. Many things would be much easier if git recorded some more metadata in every commit: file moves, and branch moves, to start with. Having some sort of notion of "parent branch" would be very useful for a number of common operations, and a "renamed file" without having to rely on client dependent heuristics too. Empty files trip people up all the time so a "create file" would fit in perfectly. These concepts would also be a good basis for more user friendly clients. Other version control systems do this the surprise factor should be low.

erik_seaberg 3y ago
People would get lazy and rename a file without telling Subversion they had done it, so it would write a “old file deleted, new file created from nothing” revision. Most of the merge conflict resolution machinery just couldn’t run without the missing guidance. Git infers someone probably renamed a file you edited or vice versa, which seems risky but works better in practice.

ziyao_w 3y ago

It's kind of funny to see Linus browbeaten other people into submission regardless of him being right or not, while claiming "I am always right". A few counter points: - `hg` has `cp`, and I believe both Meta and Google's internal systems have that; - git has `mv`, which was added later, but it is really janky and git would forget files are moved which I think it is because git doesn't try to track that, likely because of the philosophy here; - as for storing file moves - nobody said you *have* to use this information, but you can certainly use this information to help with things. The whole thread is an interesting read though and I will try going through it someday - maybe doing that would change my mind.