On 12/21/2017 3:43 PM, Jonathan Nieder wrote:
Hi,
Jeff Hostetler wrote:
Created core.aheadbehind config setting and core_ahead_behind
global variable. This value defaults to true.
This value will be used in the next few commits as the default value
for the --ahead-behind parameter.
Signed-off-by: Jeff Hostetler <jeffhost@xxxxxxxxxxxxx>
---
Documentation/config.txt | 8 ++++++++
cache.h | 1 +
config.c | 5 +++++
environment.c | 1 +
4 files changed, 15 insertions(+)
Not a reason to reroll on its own, but this seems out of order: the
series is easier to explain and easier to merge down in stages if the
patch for --ahead-behind comes first, then the config setting.
More generally, new commandline flags tend to be less controversial
than new config settings since they cannot affect a script by mistake,
and for that reason, they can go earlier in the series.
As a bonus, that makes it possible to include tests. It's probably
worth adding a test or two for this new config setting.
I'll look at restacking the commits and make this later in the
series. I have tests in a later commit that uses the config setting,
but at this point nothing uses it, so I didn't add any tests for it.
So maybe with a restacking, I can split up the tests to go with this
change.
[...]
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 9593bfa..c78d6be 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -895,6 +895,14 @@ core.abbrev::
abbreviated object names to stay unique for some time.
The minimum length is 4.
+core.aheadbehind::
+ If true, tells commands like status and branch to print ahead and
+ behind counts for the branch relative to its upstream branch.
+ This computation may be very expensive when there is a great
+ distance between the two branches. If false, these commands
+ only print that the two branches refer to different commits.
+ Defaults to true.
This doesn't seem like a particularly core feature to me. Should it be
e.g. status.aheadbehind (even though it also affects "git branch") or
even something like diff.aheadbehind? I'm not sure.
I wasn't sure where to put it after the earlier conversation in V1.
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.
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.
A value of 1 would match the "different" case in the current patch series.
For most users, a value of say 1000 would be sufficient most of the time
(and report at most a 999 a/b value), but keep us from going off into the
weeds for those ridiculous cases with very old branches.
Thanks,
Jeff
