4 ms·

> This is especially apparent in the case of rebases, where the snapshot model falls completely on its side (modifying a commit will cause the same change in al

by cerved 3y ago

> This is especially apparent in the case of rebases, where the snapshot model falls completely on its side (modifying a commit will cause the same change in all subsequent commits). I disagree. During a rebase is precisely the time the diff model is problematic. A modified commit does not cause changes in subsequent commits. Modifying commit A is modifying that commits snapshot into A~. Now the subsequent commits will be cherry-picked on top of A~. If there are subsequent commits with changes that depends on A, you have a merge conflict. A~ does not cause changes in B~, C~. The changes of B are applied on top of A~ becoming B~, the changes of C are applied on B~ etc. Thinking of commits as diffs during rebase is a recipe for confusion

goku12 3y ago
You missed the point I was making about snapshots and diffs. In git, the identity of a commit isn't a diff/change. It's a snapshot. Many operations like commit, push, fetch, etc require you to think so too. Based on that definition, the commits are essentially changed if snapshots change - even if the change introduced by them remains the same. It's clear by your own definition that B~ and C~ are not the same snapshots/commits as B and C. They have absorbed the changes from A to A~ (or the delta from A to A~ is now reflected in snapshots B~ and C~). The fact that diffs on B and C remained the same in B~ and C~ is irrelevant to the commits' identity. > Now the subsequent commits will be cherry-picked on top of A~ Here is the important point. Cherry picking is implemented as a 3-way merge. It involves actual diffing algorithm. > Thinking of commits as diffs during rebase is a recipe for confusion Here again, there are two issues. I didn't say that commit have to be thought of as diffs. I said many operations (incl rebase and cherrypicking) use diffs to propagate changes between snapshots. This reasoning is necessary to understand why snapshots B~ and C~ are different from B and C. The second part is that thinking of rebases in terms of diffs is far from a recipe for confusion (3-way merges actually, but diff is an easier approximation). It actually help me understand the operations and allowed me to predict the results of different operations in advance. That single realization actually made Git far more approachable for me and gave me the confidence that I can solve most Git issues without having to delete the copy and cloning it again.
- cerved 3y ago
  I think it's great if thinking of commits in the context of commits in a rebase as diffs works for you. I only caution against it because there are many situations during a rebase where the results can be very confusing with such a perspective. Precisely because a 3-way merge can make things much more complicated. I think you're muddling the concepts of tree (a snapshot) and commit somewhat. A commit is not merely a snapshot, it's a tree as well as metadata. > the commits are essentially changed if snapshots change - even if the change introduced by them remains the same. If by commit you mean tree, then yes. One can think of B and B~ "introducing" the same changes if the diff between A and B is the same as A~ and B~. For example, say you add a new file in A~ and then cherry-pick B on it, the tree of B~ will not be the same as B, but the diffs of A and B will be the same as A~ and B~. The main reason I caution against this perspective is that you can easily end up "introducing" other changes when you reorder commits. Change A-B-C to A-C~-B~ and very often you'll find yourself "introducing" changes from B in C~ That's not too say that doing git show REBASE_HEAD, to view the diff of B-C isn't a bad idea, just that thinking of commits as diffs during a rebase, imo, is often a false friend
  - goku12 3y ago
    > I think you're muddling the concepts of tree (a snapshot) and commit somewhat. A commit is not merely a snapshot, it's a tree as well as metadata. My intention was to approximate definitions to the bare essentials without losing too much fidelity. This criticism feels like a nitpick (apologies if that wasn't your intention) because the metadata was implied as it's well understood. > If by commit you mean tree, then yes. One can think of B and B~ "introducing" the same changes if the diff between A and B is the same as A~ and B~. That is the diff model. You are cautioning against treating commits as diffs during rebasing, and yet insist on using that definition to oppose my notion. My stand is a bit more consistent here. Treat commits as snapshots. But rebase and similar operations use diffs on those snapshots. > Change A-B-C to A-C~-B~ and very often you'll find yourself "introducing" changes from B in C~ I find this claim bizzare. The change works exactly as expected when viewed as diff (3way merge) operations. The diffs introduced by C and (B -> B~) end up in commit B~ (tree snapshot + metadata and whatever else necessary - just to be pedantic).
topaz0 3y ago
What you've described is a bunch of operations that apply diffs.

by cerved 3y ago

goku12 3y ago

You missed the point I was making about snapshots and diffs. In git, the identity of a commit isn't a diff/change. It's a snapshot. Many operations like commit, push, fetch, etc require you to think so too. Based on that definition, the commits are essentially changed if snapshots change - even if the change introduced by them remains the same. It's clear by your own definition that B~ and C~ are not the same snapshots/commits as B and C. They have absorbed the changes from A to A~ (or the delta from A to A~ is now reflected in snapshots B~ and C~). The fact that diffs on B and C remained the same in B~ and C~ is irrelevant to the commits' identity. > Now the subsequent commits will be cherry-picked on top of A~ Here is the important point. Cherry picking is implemented as a 3-way merge. It involves actual diffing algorithm. > Thinking of commits as diffs during rebase is a recipe for confusion Here again, there are two issues. I didn't say that commit have to be thought of as diffs. I said many operations (incl rebase and cherrypicking) use diffs to propagate changes between snapshots. This reasoning is necessary to understand why snapshots B~ and C~ are different from B and C. The second part is that thinking of rebases in terms of diffs is far from a recipe for confusion (3-way merges actually, but diff is an easier approximation). It actually help me understand the operations and allowed me to predict the results of different operations in advance. That single realization actually made Git far more approachable for me and gave me the confidence that I can solve most Git issues without having to delete the copy and cloning it again.

cerved 3y ago
I think it's great if thinking of commits in the context of commits in a rebase as diffs works for you. I only caution against it because there are many situations during a rebase where the results can be very confusing with such a perspective. Precisely because a 3-way merge can make things much more complicated. I think you're muddling the concepts of tree (a snapshot) and commit somewhat. A commit is not merely a snapshot, it's a tree as well as metadata. > the commits are essentially changed if snapshots change - even if the change introduced by them remains the same. If by commit you mean tree, then yes. One can think of B and B~ "introducing" the same changes if the diff between A and B is the same as A~ and B~. For example, say you add a new file in A~ and then cherry-pick B on it, the tree of B~ will not be the same as B, but the diffs of A and B will be the same as A~ and B~. The main reason I caution against this perspective is that you can easily end up "introducing" other changes when you reorder commits. Change A-B-C to A-C~-B~ and very often you'll find yourself "introducing" changes from B in C~ That's not too say that doing git show REBASE_HEAD, to view the diff of B-C isn't a bad idea, just that thinking of commits as diffs during a rebase, imo, is often a false friend
- goku12 3y ago
  > I think you're muddling the concepts of tree (a snapshot) and commit somewhat. A commit is not merely a snapshot, it's a tree as well as metadata. My intention was to approximate definitions to the bare essentials without losing too much fidelity. This criticism feels like a nitpick (apologies if that wasn't your intention) because the metadata was implied as it's well understood. > If by commit you mean tree, then yes. One can think of B and B~ "introducing" the same changes if the diff between A and B is the same as A~ and B~. That is the diff model. You are cautioning against treating commits as diffs during rebasing, and yet insist on using that definition to oppose my notion. My stand is a bit more consistent here. Treat commits as snapshots. But rebase and similar operations use diffs on those snapshots. > Change A-B-C to A-C~-B~ and very often you'll find yourself "introducing" changes from B in C~ I find this claim bizzare. The change works exactly as expected when viewed as diff (3way merge) operations. The diffs introduced by C and (B -> B~) end up in commit B~ (tree snapshot + metadata and whatever else necessary - just to be pedantic).

topaz0 3y ago

What you've described is a bunch of operations that apply diffs.