Question

I’m not entirely sure how git implements checking out, but presumably it’s deleting files on-disk (corresponding to the working copy), and writing files to the working copy from it’s internal representation. So it seems to me that if you have a project with a lot of files, git checkout ought to be an expensive thing to do, in terms of disk I/O. But it doesn’t seem to take that long usually (although maybe I’m just working with repositories small enough for it not to matter). So is git doing this in a more intelligent way than I would’ve thought, or is there some other consideration going on here, or is it in fact the case that git checkout is expensive and I’m just not noticing because I have good enough hardware?

Answer 1

If you are completely swapping between two almost completely different aspects of your project, so that the commonality is minimal, and the differences extensive, then both git and other VCS systems will need to delete and replace a whole load of data. At that point it is implementation efficiency that matters, and even there, git usually has advantages in that it has a fully local copy of your files, rather than having to endure network delays between you and the distant network repo.

If you are simply swapping between branches within rather similar versions of the project, you have a lot of pre-existing commonality, and git know this, so doesn’t need to do anything for those files. All it needs to do is a little bit of file restoration and you’re done.

Plus git is generally optimised for speed. The [e-mail] thread often has speed optimisations and speed comparisons, so it is important, which isn’t always the case with some other systems – having a local repo is key!