Hi, Jeff Hostetler wrote: > On 12/21/2017 3:43 PM, Jonathan Nieder wrote: >> I also wonder if there's a way to achieve the same benefit without >> having it be configurable. E.g. if a branch is way behind, couldn't >> we terminate the walk early to get the same bounded cost per branch >> without requiring configuration? > > I created a config setting because we don't want to force users to > type "git status --no-ahead-behind" on every interactive command to > get the benefit of it. I guess we could ask them to alias it, if we > don't want a config setting. > > Also, I didn't want to change the time-tested behavior that users see, > so I didn't want to change the algorithm in any way -- just not call it. I'm not too worried about people relying on the time-tested behavior in this case. It's a convenience feature for human users --- any scripts looking for this information would be likely to use a more convenient command like rev-list. The one exception is "git status --porcelain=v2". For that command, scripts are likely to expect to be able to parse the "+<ahead> -<behind>" line. Alas, guarding it with a config doesn't help such scripts --- they still need to be able to cope with the new behavior. git-status(1) says: Parsers should ignore headers that they don't recognize. so introducing a new line like "# branch.matchesupstream (true | false)" like you did seems reasonable enough. I *suspect* it should be okay to omit the "# branch.ab" line as long as the script didn't explicitly pass --ahead-behind but that depends on whether any scripts in the wild were relying on the "# branch.ab" line being present. > Would it make more sense to name this something like "status.aheadBehindLimit" > where 0 would mean no limit and match existing behavior and a positive > number be the number of commits we are allowed to search before giving up. Sounds good to me. Thanks, Jonathan
