3 ms·

It's true that Git mostly stores snapshots rather than deltas internally. But it's still a version control system, and I don't think it would be improved if th

It's true that Git mostly stores snapshots rather than deltas internally. But it's still a version control system, and I don't think it would be improved if the abstraction of snapshots was leaked more aggressively into the interface. You can reconstruct a delta from a snapshot and vice versa, so it still makes sense that you can apply a commit (i.e. patch, delta) in Git. One thing about Subversion that I miss in Git: when you move a file or a directory, Subversion tracks where it came from. That's not true in Git, which just stores snapshots (mostly) and has to guess whether a file was moved. That means that `svn log FILE` behaves like `git log --follow FILE` by default (except always right rather than "right when the heuristics work"), which is much more useful. One thing I dislike about Git is that its history model tends to crumble when you move files and directories around.

vlovich123 5y ago
It is kind of frustrating that git doesn’t remember when you tell it you moved something. On the other hand, it’s also convenient to be able to mv something and just have git figure that out. Another case git does better in is when you do complex refactors. So loving the bulk of the content of one file to another is recognized as a move whereas SVN wouldn’t help you. All in all, it’s a hard problem and there’s no perfect answer I think.
- rectang 5y ago
  There's a solution which works most of the time, and it works equally well in Subversion and Git. Divide up the change into two commits: 1. Move the file verbatim. 2. Change the file as necessary. Subversion will remember the move because it always does — Subversion stores changesets internally, and those changesets contain history metadata. Git won't track the move, but when you run `git log --follow` later it detects that the file was moved because the content of the file that was added was the same as something which existed before. It's a little awkward if only a small portion of a file was migrated, though. In such a case, you may just have to fall back to documenting in the commit message that code was moved. This approach has another benefit: it is easy to review. The first commit can be validated as "verbatim move — check!". Then the logical change can be validated with effort proportional to the amount that was changed. In contrast, if you lump them all together, it can be hard to discern what changed when presented with a huge diff containing mostly verbatim move but also a few subtle changes.

vlovich123 5y ago

It is kind of frustrating that git doesn’t remember when you tell it you moved something. On the other hand, it’s also convenient to be able to mv something and just have git figure that out. Another case git does better in is when you do complex refactors. So loving the bulk of the content of one file to another is recognized as a move whereas SVN wouldn’t help you. All in all, it’s a hard problem and there’s no perfect answer I think.

rectang 5y ago
There's a solution which works most of the time, and it works equally well in Subversion and Git. Divide up the change into two commits: 1. Move the file verbatim. 2. Change the file as necessary. Subversion will remember the move because it always does — Subversion stores changesets internally, and those changesets contain history metadata. Git won't track the move, but when you run `git log --follow` later it detects that the file was moved because the content of the file that was added was the same as something which existed before. It's a little awkward if only a small portion of a file was migrated, though. In such a case, you may just have to fall back to documenting in the commit message that code was moved. This approach has another benefit: it is easy to review. The first commit can be validated as "verbatim move — check!". Then the logical change can be validated with effort proportional to the amount that was changed. In contrast, if you lump them all together, it can be hard to discern what changed when presented with a huge diff containing mostly verbatim move but also a few subtle changes.