On 6/21/2019 12:33 PM, Junio C Hamano wrote:
"Jeff Hostetler via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
From: Jeff Hostetler <jeffhost@xxxxxxxxxxxxx>
The --[no-]ahead-behind option was introduced in fd9b544a
(status: add --[no-]ahead-behind to status and commit for V2
format, 2018-01-09). This is a necessary change of behavior
in repos where the remote tracking branches can move very
quickly ahead of the local branches. However, users need to
remember to provide the command-line argument every time.
Add a new "status.aheadBehind" config setting to change the
default behavior of all git status formats.
Signed-off-by: Jeff Hostetler <jeffhost@xxxxxxxxxxxxx>
Signed-off-by: Derrick Stolee <dstolee@xxxxxxxxxxxxx>
---
Documentation/config/status.txt | 5 +++++
builtin/commit.c | 17 ++++++++++++++++-
t/t6040-tracking-info.sh | 31 +++++++++++++++++++++++++++++++
t/t7064-wtstatus-pv2.sh | 4 ++++
4 files changed, 56 insertions(+), 1 deletion(-)
diff --git a/Documentation/config/status.txt b/Documentation/config/status.txt
index ed72fa7dae..0fc704ab80 100644
--- a/Documentation/config/status.txt
+++ b/Documentation/config/status.txt
@@ -12,6 +12,11 @@ status.branch::
Set to true to enable --branch by default in linkgit:git-status[1].
The option --no-branch takes precedence over this variable.
+status.aheadBehind::
+ Set to true to enable `--ahead-behind` and false to enable
+ `--no-ahead-behind` by default in linkgit:git-status[1] for
+ non-porcelain status formats. Defaults to true.
Sensible.
@@ -1078,9 +1078,11 @@ static const char *read_commit_message(const char *name)
static struct status_deferred_config {
enum wt_status_format status_format;
int show_branch;
+ enum ahead_behind_flags ahead_behind;
} status_deferred_config = {
STATUS_FORMAT_UNSPECIFIED,
- -1 /* unspecified */
+ -1, /* unspecified */
+ AHEAD_BEHIND_UNSPECIFIED,
This obviously is not a problem introduced by this patch, but is
there a plan to extend this beyond a boolean?
Otherwise, a separate enum is way overkill. Naming the field so
that it is clear it is either true or false (e.g. perhaps call it
"ahead_behind_detailed" as the current "QUICK" is merely "are they
equal?" which corresponds to "false", and "FULL" is to show the
detailed info), and then use the usual "-1 is unspecified, 0 and 1
are usual bools" convention would be more appropriate.
At one point[1] we talked about having an intermediate option
to try N or less commits before giving up. The enum would let
us add that case if we wanted it.
So far, I've not heard any complaints with just having QUICK or FULL
from our Windows developers, so adding a 3rd mode hasn't been a
priority. But the enum is here if we do decide to do so.
Jeff
[1]
https://public-inbox.org/git/20180111093943.GC9190@xxxxxxxxxxxxxxxxxxxxx/
