From: Jeff Hostetler Date: Wed, 26 Jun 2019 20:02:17 GMT Subject: Re: [PATCH 1/3] status: add status.aheadbehind setting Message-ID: In-Reply-To: On 6/21/2019 12:33 PM, Junio C Hamano wrote: > "Jeff Hostetler via GitGitGadget" writes: > >> From: Jeff Hostetler >> >> 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 >> Signed-off-by: Derrick Stolee >> --- >> 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@sigill.intra.peff.net/