Indeed, that's the case. You can rewrite _history_ in git, squashing commits, rebasing chains of commits, etc., but a single commit is effectively immutable because its identity is defined by the SHA-1 hash [1] of its contents: "altering" a commit means creating a new commit with a new identity. [1] Meaning of course that you CAN alter a commit without changing its identity: "simply" find a SHA-1 collision! frank On 15 May 2012 00:14, Dale Henrichs <dhenrich@vmware.com> wrote:
I think you are referring to the the fact that there are ways to go through commits and remove sensitive data from them, however, unless I'm mistaken, the SHA of the commit gets changed when you modify it, so you may have "modified a commit" but you have done so by copying it to  a new identity. The original commit with the origin SHA still exists and is accessible unless you take further steps to delete the specific commit, so in the end the commit _is_ immutable.
Dale
----- Original Message ----- | From: "Douglas Brebner" <squeaklists@fang.demon.co.uk> | To: pharo-project@lists.gforge.inria.fr | Sent: Monday, May 14, 2012 3:07:00 PM | Subject: Re: [Pharo-project] Semantic Versioning | | On 14/05/2012 17:51, Dale Henrichs wrote: | | One of the appeals of git/github is that a git commit is immutable so | all of the artifacts in a commit are guaranteed. | Are you sure? It was my understanding that you can alter a git | commit. Not advisable, but possible. |