Creating a duplicate git commit

I was wondering if it is possible to create two commits with the same hash.

Let’s just say I’m on the master branch and I create a new branch called foo. Now let’s say that I have two terminal sessions that are both authorized as the author Now let’s say that on one terminal session is on master and another terminal session is on foo and both of the branches have the exact same staged changes. Now let’s say that I run the git commit command at the exact same time in both terminal sessions…

  • How can I undo git reset --hard HEAD~1?
  • Get parents of a merge commit in git
  • How do I merge back into remote branch
  • git bad config when piping commands
  • Magit revert single file
  • How to launch and edit a file from Git using Notepad++?
  • Wouldn’t the two commits end up having the same hash value?

  • Convert line-endings for whole directory tree (Git)
  • Git alias to delete remote branch
  • Git unable to create file permission denied
  • git: Your branch is Ahead by X commits
  • EGit showing directory as always dirty
  • Prevent 'git checkout' if uncommitted changes
  • One Solution collect form web for “Creating a duplicate git commit”

    Yes, it is theoretically possible that you encounter this situation. The commit hash is generated from the content of the commit object, which are:

    • The commit message
    • The author name
    • The authoring timestamp
    • The committer name
    • The commit timestamp
    • The list of parent commits
    • The tree object reference

    The tree object reference is an object hash itself, consisting of references to blob objects and subtrees. So it will be identical for an identical tree of files.

    So if all those properties of the commit are identical, then yes, you would end up with the same hash. This can absolutely be constructed if you use the same author and commit at the exact same time; since the resolution of the timestamp is only in seconds, you don’t even need to be that precise.

    But is this a problem in practice? Not really: You would usually not commit with the same user at the same time; instead, you would have separate contributors with their own identity working on their own stuff. So the probability of commits getting the same hash is near zero.

    But even if this situation happened in practice. Would there be a problem? No. The commits are identical by definition (and by construction). So they are the same. And they are compatible with each other, so when you push or pull later, it will just look as if you already had that commit and just nothing happens.

    Of course, there is the remaining problem of hash collisions due to the limited hash space of SHA1. This can become a possible problem in very large repositories, but I haven’t heard of it happening yet—although there are already repositories of gigantic sizes. But even if it happened for one of those, it would not affect other repositories with more managable sizes.

    Git Baby is a git and github fan, let's start git clone.