On Wed, Dec 20, 2017 at 02:42:41PM +0000, Jeff Hostetler wrote: > From: Jeff Hostetler <jeffhost@xxxxxxxxxxxxx> > > This patch series adds a "--no-ahead-behind" option to status > to request that it avoid a possibly expensive ahead/behind > computation for the current branch. Instead, it just prints a > not up to date message in place of the detailed counts. > > This idea was previously discussed in [1]. Working with the > enormous Windows repository, we found that 20+ seconds was being > spent in the ahead/behind computation when the current branch was > 150K commits behind the upstream branch. (Yes, this happens and > only took 3 weeks on the reporter's system.) Overall this looks cleanly done. I raised a few minor points in the individual patches, but certainly nothing that would be a show-stopper for the general idea. > I've only modified "git status" in this patch series. A similar > change could be added to "git branch -vv" and "git checkout" to > avoid delays there too. I avoided doing it here to keep this > patch series focused. I have a feeling that the same user who got annoyed by "git status" is going to get annoyed by "git checkout" sooner or later. I'm OK with handling the other commands separately, but I suspect we may want at least "git checkout" support in the near future. There is one thing that it's worth thinking about (because it will be hard to take back later): config option naming. If your repository is so large that ahead/behind checks are annoying, would you want to be able to set a single config to tell Git that, rather than one for each command? If so, then do we want to ditch "status.aheadbehind" in favor of a more unified name? -Peff
