3

I'm mostly integrating finished topic branches into the main development branch, in git. While doing that I sometimes have to change the message of commit (improving, correcting spelling, ...) which results into a new commit with new SHA1 ID.

I would like to get the SHA1 hash of the changes in a commit. This would let us verify if any content of the changeset is altered or not after modyfying the commit message.

It would be great if we could get the SHA1 hash of the changeset of a sequence of commits too. Then we would be able to do interactive rebases where we squash commits and still end up with the same SHA1 hash of the changeset.

Paul Pladijs
  • 18,628
  • 5
  • 28
  • 31
  • Why do you even need this? Don't you believe git that it does what you say it to do? – svick May 22 '11 at 11:51
  • I do believe git but other people (including me) are altering commits (normally only the commit message) but we need proof that the changesets are not altered. – Paul Pladijs May 22 '11 at 12:08

2 Answers2

2

When git needs to tell whether a patch has already been applied, e.g. for git cherry, it uses git-patch-id to create a hash of the patch introduced by that commit. Perhaps that would suit what you're wanting to do? Or perhaps git cherry already does what you want? The documentation for those commands are:

Mark Longair
  • 446,582
  • 72
  • 411
  • 327
1

You can get the SHA1 hash of the tree certain commit points to using

git show -s --pretty=format:%T master

where master is any commit specification.

Note that git doesn't track changesets, it tracks the whole repository, so this tree id represents the state of the whole repository after that commit, not the changes that were added by that commit.

svick
  • 236,525
  • 50
  • 385
  • 514
  • This *might* be what the OP needs - if the commit metadata has been altered, the tree will certainly be the same, and the OP will be able to detect "safely altered" commits as desired. However, if people are rebasing commits, so that the diff is the same but they're applied somewhere else, the trees would have changed... – Cascabel May 22 '11 at 13:01
  • Good idea. This works well as long the branch is not rebased. (Unfortunately) rebasing is part of our workflow. – Paul Pladijs May 30 '11 at 13:51