4 ms·

> But they are not immutable in the sense that you couldn’t change the history of e.g. a branch. That sentence doesn't make sense, though. Assuming from contex

> But they are not immutable in the sense that you couldn’t change the history of e.g. a branch. That sentence doesn't make sense, though. Assuming from context that `they` = commits, "[commits] are not immutable in the sense you couldn't change the history of a branch" Branches and tags are mutable - they're just pointers to commits - but that doesn't change whether or not commits are immutable. When you "change" the history of a branch, what git is really doing is creating another series of new commits, and then making the branch pointer point to the new commits. However, because commits are immutable, the old commits are still there, and at any time you can go back.

deleted 4y ago
[deleted]
layer8 4y ago
You are defining commits to be different by the mere fact that their contents (and history) is different. With that definition, how could a commit ever be mutable? Only by an indirection were the VCS allows the referencee to change. And that is exactly what Git allows with branches. When rewriting history, the fact that the “new” commits are new is a tautology if you define commits to be different when their contents is different. This only matters when you use the commit hash as your reference point, which is what I was pointing out in the parent comment. The expectation of immutable commits would be that history never gets lost and cannot be changed (without rewriting history into a different repository), but it certainly can in Git. The real point about Git’s content-derived addressing is that it enables the distributed aspect, because it makes the path a commit has taken between repositories not matter. But that is already better expressed in point 3.
- ajanuary 4y ago
  > With that definition, how could a commit ever be mutable? It can’t. Hence commits in git are immutable. It’s a function of gits design that commits are immutable. I could make my own VCS that doesn’t use content derived addressing, but instead uses UUIDs for commit IDs, and let you issue commands that changes the contents of that commit. In that system, commits are mutable. But that isn’t git. > The expectation of immutable commits would be that history never gets lost and cannot be changed No it isn’t. The expectation of immutable commits is that a commit object can’t be changed. And in git that is true, at least it can’t be changed without also changing its identity, which is functionally the same. As has been explained, you can make an alternative parallel history, and you can switch to using that new parallel history as you’re new truth, but you haven’t changed the original commits. They remain un-mutated, because they are immutable.

deleted 4y ago

[deleted]

layer8 4y ago

You are defining commits to be different by the mere fact that their contents (and history) is different. With that definition, how could a commit ever be mutable? Only by an indirection were the VCS allows the referencee to change. And that is exactly what Git allows with branches. When rewriting history, the fact that the “new” commits are new is a tautology if you define commits to be different when their contents is different. This only matters when you use the commit hash as your reference point, which is what I was pointing out in the parent comment. The expectation of immutable commits would be that history never gets lost and cannot be changed (without rewriting history into a different repository), but it certainly can in Git. The real point about Git’s content-derived addressing is that it enables the distributed aspect, because it makes the path a commit has taken between repositories not matter. But that is already better expressed in point 3.

ajanuary 4y ago
> With that definition, how could a commit ever be mutable? It can’t. Hence commits in git are immutable. It’s a function of gits design that commits are immutable. I could make my own VCS that doesn’t use content derived addressing, but instead uses UUIDs for commit IDs, and let you issue commands that changes the contents of that commit. In that system, commits are mutable. But that isn’t git. > The expectation of immutable commits would be that history never gets lost and cannot be changed No it isn’t. The expectation of immutable commits is that a commit object can’t be changed. And in git that is true, at least it can’t be changed without also changing its identity, which is functionally the same. As has been explained, you can make an alternative parallel history, and you can switch to using that new parallel history as you’re new truth, but you haven’t changed the original commits. They remain un-mutated, because they are immutable.