Git's criteria for comparing commits, why include the committer?

Question

Git uses SHA1 hash to identify a commit object, and according to the Git Book a commit object contains :

• a tree
• a pointer to an older commit (parent)
• a timestamp
• author's name
• commiter name
• ...

What surprises me is the need for both author and commiter in a commit object, indeed it is rapidly a problem when merging a commit to another identical repository, since the commit hash would change!

My point is illustrated by GitHub, in your Fork Queue you can even find your own commit once your changes have been merged with the originating project! It is typically a "metaconflict", because whoever originated the change is the same, and who commits shouldn't change the nature of the commit...

So, why the need ? Is it a misuse of author and commiter ? I understand the need of both, I don't get why both should be included in a commit hash, and why not somewhere else?

Can one not agree that the same change committed in different repos should be identified as the same, so exclude the commiter's name from the hash ?

Answer 1

The commiter field allows you to retain authorship even when someone other than the author commits to the tree. This is crucial in "pull" development models where maintainers pull in changes from individual developers who might not be allowed to push directly to the repository. In a version control system without these fields, the author will appear to be whoever had permission to push the change.

Having both also helps in identifying who actually committed a change to a particular branch since the author may have developed a change in one branch, but it was then cherry-picked to another.

Answer 2

The identification as mentioned is key.

This will all start to make a lot more sense when you realize that Git is able to strongly sign commits; that way no one can forge a history, not even the names of the persons responsible :)

---

To the comment: Git is also about trust, verifiability of sources. In a few words: the committer is responsible for the commit and signs it (literally); the author is the one who submitted the patch in the first place - this could be someone 'on the outside', someone 'untrusted'. (_if you have trouble getting your head around this, consider the Linux kernel project, re security vulnerabilities or backdoors: users of Linux have a real need to verify that the kernel they use has been moderated by trusted community members!

---

Additional info: The "Real" Question

In the case I used as an example, I am the author of a commit, it is commited by the owner of the master project, when I look at my fork queue, I see my own commit (same author) asked to be committed (again) to my fork ? There's no way to tell it is the same thing!

Ah there is the real question! So you are not worried about why the commit is checksummed including comment and other metadata. You also don't worry why there are committer and author fields[1]

You are annoyed by the fact that a merged commit has a different commit id unless it was a ff (fast-forward) merge. Now there is a good question! Here's the answer:

A commit ID depends on the parent commits as well, so a commit ID can only ever be the same when

1. the parent ID is the same
2. the committed tree 'snapshot' is the same

The only case when this happens is with forks (refs to identical commits) and fast-forward merges (resulting in... identical refs)[2].

So as soon as you merge, cherry-pick, or rebase (three similar operations, in this context) even a single commit onto a different branch (read under a different parent commit), it will by definition have a different commit ID, regardless of what metadata is checksummed. This is because the tree history is different, and this is the only relevant metadata at this point.

The real question is: how do you avoid seeing the duplicate commits?

• prefer merge over cherry-pick/rebase

  • when merging, the resulting commit will have two parent commits; this enables git to do merge tracking and automatically eliminate overlapping commits (i.e. that have already been merged). git diff, git merge-base, git log rev1 ^rev2, git show-branch all honour this logic). This is why repeated merges (criss-cross, dove-tail etc) work 'magically' on git. [3]

    • SKEPTICS: if you send a pull request to an upstream, they may not merge your branch, making this advice 'hard' to achieve. However, nothing stops you

      • merging their branch after they accepted your work (same end result, a bit more work)
      • rebasing your own branch off theirs after they accepted your work (same end result)

.

• use e.g. git log --left-right --graph --oneline --cherry-pick BRANCH1...BRANCH2 to inspect differences between branches where cherry-picks or rebases have occurred. From the manpage this does exactly what YOU wanted:

  --cherry-pick
       Omit any commit that introduces the same change as another commit on the "other side" when the set of commits are limited with symmetric
       difference.

       For example, if you have two branches, A and B, a usual way to list all commits on only one side of them is with --left-right, like the example
       above in the description of that option. It however shows the commits that were cherry-picked from the other branch (for example, "3rd on b" may
       be cherry-picked from branch A). With this option, such pairs of commits are excluded from the output.

• lastly, if your situation is one of frequent merges with recurring conflict (such as when consuming non-central topic-branches) see `git rerere --help, which is beyond the scope of this answer for me.

[1] you don't even worry about commit notes, that are out-of-band and not revisioned nor checksummed ... sic

[2] In techno babble: commit histories form cryptographically strong merkle trees. When the sha1 sum of the tip commit (HEAD) matches, it mathematically follows that (a) tree content (b) the branch history (including all sign-offs and committer/author credentials) are identical. This is a huge security feature of git, and other SCMs that feature this.

[3] see also git log --merges --boundaries --decorate and revision specs like rev1...rev2 (mind the three dots; see man git-rev-parse)