Kevin D <me@xxxxxxxxx> writes: > On Sat, Mar 07, 2015 at 01:30:07AM +0000, Ken Moffat wrote: >> Hi, please CC me if that is not your usual fashion, because I am not >> subscribed. >> >> I use git for my build scripts - those are accessed over nfs. Since >> I started using 2.1 and later (I don't think I used 2.0) commands >> such as 'commit' take a long time before anything happens. I >> assumed that the newer version meant this would take longer. >> >> But today^Wyesterday I was bisecting the kernel on a local >> filesystem - even when the number of revisions left to test was in >> the single digits, git bisect took a long time to decide which >> revision should be the next one to test. The filesystems are ext4. >> Is this sort of delay normal now? >> >> What really prompted me to ask is that I ran git blame on a script, >> to see when I made a particular change so that I could add that >> information to a ticket, and almost gave up waiting because it felt >> as if it was taking for ever. >> > > What kind of repository are we talking about? How many files, how big? > Git should not have become significantly slower recently. Particularly not git-blame in 2.1. I should be quite surprised to see any git-blame call running noticeably slower in 2.1 than in any preceding version. What may have happened is that the repository recently got repacked aggressively and thus any access to older revisions got slower. However, that change would be mostly tied to the repository rather than the version of Git you access it with. -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html