5 ms·

> moving files isn't stored in git is there an intuitive and enlightening explanation as to why it is this way?

keybored 3y ago
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.
paulddraper 3y ago
Git doesn't store any individual changes: files moved, lines added, line deleted, etc. It stores a commit graph, and a tree at each of those commits. (A lossless compression algorithm deduplicates information.) There's no need for the author to be concerned with what diffing information gets incorporated into the commit. Diffs are up to the viewer of the commit history. git show --diff-algorithm=...
layer8 3y ago
For the historical rationale see here: https://gist.github.com/borekb/3a548596ffd27ad6d948854751756a08 https://gist.github.com/borekb/3a548596ffd27ad6d948854751756... In short, Linus stance is that file renaming doesn’t matter, only the contents of files matter, and the moving of contents between files. Moved/renamed files then fall out as a special case of moving content. Personally, I think this is a case of the better being the enemy of the good, and his “clearly superior algorithm” doesn’t work as well as claimed in practice. Or maybe tooling merely still isn’t up to snuff after 18 years.
- seba_dos1 3y ago
  I don't think it's about having a stance, it's about git's architecture. From the commit graph point of view, there's no such things as moving anything at all, neither files nor content. Commits represent a whole new state of the repository, not a diff from the previous state. The only way a commit is linked to the previous state is via parent pointer, it can otherwise be completely unrelated (and you can simply change the parent pointer without changing anything else in the commit). Any diffs are calculated at runtime. The issue with renames is just a consequence of assuming such data model - you could try to plaster it over with some metadata, but ultimately you would still be fighting against the model rather than working with it. Many people develop a bad mental model with commits as diffs, because that's what the UI makes them think commits are. It can work for a while, but inevitably leads to confusion later on.
  - layer8 3y ago
    As you say, commits link to their parent(s), and those links effectively represent the edges of the commit graph. It makes perfectly sense to record moves on those edges. That’s how other VCSs do it. There is no conflict with the commit model. Viewing the commit graph in terms of nodes (commits) or edges (diffs) is equivalent, these are dual views you can easily convert between. The internal representation is independent from that. Some VCSs use a mix of diffs and full revisions internally. Even Git uses delta compression when packing objects.
    - 3y ago

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.

paulddraper 3y ago

Git doesn't store any individual changes: files moved, lines added, line deleted, etc. It stores a commit graph, and a tree at each of those commits. (A lossless compression algorithm deduplicates information.) There's no need for the author to be concerned with what diffing information gets incorporated into the commit. Diffs are up to the viewer of the commit history. git show --diff-algorithm=...

layer8 3y ago

For the historical rationale see here: https://gist.github.com/borekb/3a548596ffd27ad6d948854751756a08 https://gist.github.com/borekb/3a548596ffd27ad6d948854751756... In short, Linus stance is that file renaming doesn’t matter, only the contents of files matter, and the moving of contents between files. Moved/renamed files then fall out as a special case of moving content. Personally, I think this is a case of the better being the enemy of the good, and his “clearly superior algorithm” doesn’t work as well as claimed in practice. Or maybe tooling merely still isn’t up to snuff after 18 years.

seba_dos1 3y ago
I don't think it's about having a stance, it's about git's architecture. From the commit graph point of view, there's no such things as moving anything at all, neither files nor content. Commits represent a whole new state of the repository, not a diff from the previous state. The only way a commit is linked to the previous state is via parent pointer, it can otherwise be completely unrelated (and you can simply change the parent pointer without changing anything else in the commit). Any diffs are calculated at runtime. The issue with renames is just a consequence of assuming such data model - you could try to plaster it over with some metadata, but ultimately you would still be fighting against the model rather than working with it. Many people develop a bad mental model with commits as diffs, because that's what the UI makes them think commits are. It can work for a while, but inevitably leads to confusion later on.
- layer8 3y ago
  As you say, commits link to their parent(s), and those links effectively represent the edges of the commit graph. It makes perfectly sense to record moves on those edges. That’s how other VCSs do it. There is no conflict with the commit model. Viewing the commit graph in terms of nodes (commits) or edges (diffs) is equivalent, these are dual views you can easily convert between. The internal representation is independent from that. Some VCSs use a mix of diffs and full revisions internally. Even Git uses delta compression when packing objects.
  - 3y ago