On 1/8/2018 10:48 AM, Jeff Hostetler wrote:
From: Jeff Hostetler <jeffhost@xxxxxxxxxxxxx> This is version 4 of my patch series to avoid expensive ahead/behind calculations in status. This version removes the last commit containing the experimental config setting. And removes the undefined return values for the nr_ahead/nr_behind arguments as discussed on the mailing list.
While I like the simplicity of just turning this off completely, I do wonder if we could come up with a better user experience. For example, could we somehow limit the time spent computing the before/after and if it exceeds that limit, drop back to saying they are "different" rather than computing the exact number of commits before/after.
I was thinking about something similar to the logic we use today about whether to start reporting progress on other long commands. That would mean you could still get the ahead/behind values if you aren't that far behind but would only get "different" if that calculation gets too expensive (which implies the actual value isn't going to be all that helpful anyway).
This version does not address "git branch -vv", but that requires passing data across the for-each-ref barrier and that seemed beyond the scope of this task. Jeff Hostetler (4): stat_tracking_info: return +1 when branches not equal status: add --[no-]ahead-behind to status and commit for V2 format. status: update short status to respect --no-ahead-behind status: support --no-ahead-behind in long format Documentation/config.txt | 6 ++++ Documentation/git-status.txt | 5 +++ builtin/checkout.c | 2 +- builtin/commit.c | 18 ++++++++++- ref-filter.c | 8 ++--- remote.c | 50 ++++++++++++++++++++---------- remote.h | 12 ++++++-- t/t6040-tracking-info.sh | 73 ++++++++++++++++++++++++++++++++++++++++++++ t/t7064-wtstatus-pv2.sh | 69 +++++++++++++++++++++++++++++++++++++++++ wt-status.c | 41 +++++++++++++++++-------- wt-status.h | 2 ++ 11 files changed, 250 insertions(+), 36 deletions(-)
