Can the version of Git vary between team members?

Question

We are about 40 developers working on the same code base and we use Git for version control.

My question is: can there be problems if, for example, some developers have a much older version of Git installed on their system ? Or should we try to enforce some rule that says something like "you should upgrade Git on your machine to the latest version at least once per year" ?

Maybe in older versions of Git, the structure of the objects may be slightly different. Or there may be some bugs in the algorithm that calculates which lines were added/removed from files. These issues can cause corrupt repositories or different values for the SHA-1 hashes in places where it should have the same value.¹

Obviously, since Git is a distributed VCS, a corrupt repository won't ever mean critical loss of data, since there are 40 other people from which you can clone a new copy.

So it's more a curiosity than a concern. I suspect that backwards-compatibility is something extremely important when it comes to releasing a new version of Git; but still: the potential issues mentioned above are a possibility.

¹ = as far as I know, we had no such problems... yet.

Answer 1

The repository format only changes very rarely, and it never changes in a way that is backwards-incompatible. IIRC, the last incompatible changes in repository format were back during the original 12-day period when Linus wrote Git, i.e. even before he published the code.

I think there was one backwards-incompatible change in one of the remote protocols many many years ago. However, in that case, the server will tell you that you have to upgrade your client and even which minimum version to upgrade to.

Of course, if you go far enough back you will arrive at a version that doesn't even know the current HTTP protocol at all.

But in all of the above cases, we are talking about clients that are several years out of date.