Jeff King [off-list ref] writes:
... But I don't know
if this counts as critical (it is for you, certainly, but I don't think
that many people are affected, as the crucial factor here is really the
slow NFS filesystem operations).
If it is critical to some people, they can downmerge to their custom
old installations of Git they maintain with ease, of course, and
that "with ease" part is the reason why I try to apply fixes to tip
of the original topic branch even though they were merged to the
mainline eons ago ;-).
Thanks. The patches look good from cursory reading.
On Mon, Apr 20, 2015 at 01:04:11PM -0700, Junio C Hamano wrote:
Jeff King [off-list ref] writes:
quoted
... But I don't know
if this counts as critical (it is for you, certainly, but I don't think
that many people are affected, as the crucial factor here is really the
slow NFS filesystem operations).
If it is critical to some people, they can downmerge to their custom
old installations of Git they maintain with ease, of course, and
that "with ease" part is the reason why I try to apply fixes to tip
of the original topic branch even though they were merged to the
mainline eons ago ;-).
I think it is a bigger deal for folks who do not ship a custom
installation, but expect to ship a third-party system that interacts
with whatever version of git their customers happen to have (in which
case they can only recommend their customers to upgrade).
I don't know how Stash or GitLab installations work. GitHub ships our
own custom git (which I maintain), though we are already on 2.3.x.
Either way, though, I do not think it is the upstream Git project's
problem.
-Peff
quoted
If it is critical to some people, they can downmerge to their custom
old installations of Git they maintain with ease, of course, and
that "with ease" part is the reason why I try to apply fixes to tip
of the original topic branch even though they were merged to the
mainline eons ago ;-).
I think it is a bigger deal for folks who do not ship a custom
installation, but expect to ship a third-party system that interacts
with whatever version of git their customers happen to have (in which
case they can only recommend their customers to upgrade).
Yes, this is the situation we are facing. We allow our customers to
use the git version that is supported/available on their OS (within a
certain range of supported versions) so our customers usually don't
compile from source.
Either way, though, I do not think it is the upstream Git project's
problem.
That's fair enough, I was mostly enquiring about the official git
versions this will land in so that we can advise customers what git
version to use (or not to use).
I've noticed Peff's patches on pu which suggest they will be available
in git 2.5?
Do you Junio, have plans to merge them to maint (2.3.x) and/or next (2.4)?
While I certainly agree that this is specific to Git on NFS and not a
more widespread git performance problem, I'd love to be able to
message something other than "skip all the git version between and
including git 2.2 - 2.4".
I appreciate your consideration and thanks again for the swift response on this.
Cheers,
Stefan