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…

  • Gitlab/Gitolite issue while cloning repo
  • Make git ignore the date in PDF files
  • How to use GIT PULL from the command line?
  • Unable to run git diff on a file that has moved
  • Gerrit Trigger on multiple SCM in jenkins not working
  • Automatic deploy on commit
  • Wouldn’t the two commits end up having the same hash value?

  • Git: pull from repository, remotely
  • How to have two remote origins for Git?
  • Git commit lost after merge
  • Concourse GIT errors on puts to git resource
  • How can I view original branch of commits (and file changes) using git log?
  • Getting error “Updates were rejected because the tip of your current branch is behind”
  • 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.