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…

  • Migrate from Subversion to git, clone all branches and push through gitolite?
  • ignore my changes in files but don't delete them from remote rep
  • Want git post receive hook to make new commit and push
  • Is git svn compatible with git subtree?
  • What are your coolest/most unusual hacks using a distributed version control system?
  • GIT: error: pathspec 'xxx did not match any file(s) known to git
  • Wouldn’t the two commits end up having the same hash value?

  • Automatic merge branch into master on sucessful build in travis
  • Squash commits directly on feature without rebase or merge
  • How to remove a too large file in a commit when my branch is ahead of master by 5 commits
  • Is it possible to configure and per wildcard domains in .gitconfig?
  • How can I add/update a submodule, using an existing repository to save bandwidth?
  • How to merge a branch into another branch in Git while maintaing the old lines?
  • 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.