-1

Is there a fixed time-length to perform a git commit, or is it dependent on the file which we are committing? Also, how much time does git take to restore a previous version?

Ujan Mukhopadhyay
  • 11
  • 2
  • it depends on branch size. But normally it doesn't take more than 2 minutes. – Farhan Ali Feb 21 '19 at 05:41
  • 1
    Please read [this SO question](https://stackoverflow.com/questions/8198105/how-does-git-store-files) which directly discusses the doubts you have in mind. Doing a Git commit won't necessarily depend so much on the file _size_, as much as the size of the new content which isn't already present somewhere in your repo. So, assuming a completely new file comes in which is large, then it would take longer to commit than new file which is relatively small. – Tim Biegeleisen Feb 21 '19 at 05:43
  • an additional variable is: where are you pushing/pulling to/from? If you're just talking about your local repository, everything should be pretty much instantaneous – Kai Feb 21 '19 at 05:58
  • @Kai Committing is always local, and OP didn't mention push/pull. You don't even need to have a remote to use git. – Romain Valeri Feb 21 '19 at 07:46
  • @RomainValeri yeah, obviously. OP was asking about time, which is not even a factor with committing, but becomes relevant with remote repos – Kai Feb 21 '19 at 08:05
  • @Kai But I had the feeling that it was precisely the matter of the question : at which point is this usually near-instantaneous operation (committing) becoming a noticeable time cost? Also, I admit this is what got me interested in the question, so I might have a slight bias here. – Romain Valeri Feb 21 '19 at 08:35

1 Answers1

2

The git commit command writes some number of tree objects and one commit object, then stores the one commit object's hash ID into the current branch. The set of tree objects is determined by the contents of the index. You can view these contents directly using git ls-files --stage.

The time needed to write each of these objects is generally quite small, so in most cases, git commit is nearly instantaneous. The number of tree objects needed depends on the number of sub-trees required by the index contents. This is harder to count easily. Examining the number of slashes in file names within the index is a start, but if the index contains files a/b, a/c, and so on through a/z, that's just one sub-tree (for a/) for all of these files. If the index contains a/b/c and a/c/d, there's one subtree for b/ and one for c/ without a/, plus the tree for a/ itself, which makes three trees total. So just counting slashes overestimates, sometimes wildly so, depending on how well-populated each subtree is.

Note that the files themselves are already stored in the compressed Git-only format at the time you run git commit. If you examine that git ls-files --stage output, you'll see a big ugly hash ID for each file. That hash ID represents the blob object that already has the files' content stored in the repository. The git commit command merely refers to that existing content: there is no need to write a new file.

(The time taken to copy a file out of the repository, from its special compressed Git-only form to ordinary form on disk, is roughly proportional to the file's size. The time taken to copy a file from its ordinary form on disk, into the repository, during git add, is also roughly proportional to the file's size. But once in, committing the file is very fast. Switching to another commit that has the same version of the file takes no time as Git notices that the file in the index and in the work-tree match the file in the target commit. Switching to a commit that has a different version of the file requires extracting the file from the commit and index, into the work-tree, falling into the "copy out of repository to ordinary form" case.)

torek
  • 448,244
  • 59
  • 642
  • 775