git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jonathan Nieder <jrnieder@gmail.com>,
	Jeff Hostetler <git@jeffhostetler.com>,
	git@vger.kernel.org, Jeff Hostetler <jeffhost@microsoft.com>
Subject: Re: [PATCH v2 1/5] core.aheadbehind: add new config setting
Date: Sun, 24 Dec 2017 09:33:18 -0500	[thread overview]
Message-ID: <20171224143318.GC23648@sigill.intra.peff.net> (raw)
In-Reply-To: <xmqq3742tyho.fsf@gitster.mtv.corp.google.com>

On Fri, Dec 22, 2017 at 10:21:23AM -0800, Junio C Hamano wrote:

> >> +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.
> 
> FWIW, I do not think it is core at all, either; sorry for not
> anticipating that a wrong name will be picked without a proper
> guidance when I saw the "not limited to status" mentioned in the
> discussion, but I was sick and offline for a few days, so...

I, too, had a funny feeling about calling this "core". But I didn't have
a better name, as I'm not sure what other place we have for config
options that cross many command boundaries. "diff" and "status" don't
seem quite right to me. While you can argue they are subsystems, it
seems too easy for users to confuse them with the commands of the same
names.

Maybe there should be a "ui.*" config hierarchy for these kinds of
cross-command interface options?

> > 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?
> 
> Hmm, that is an interesting thought.

Yes, it is. Two thoughts:

  - It probably doesn't let us punt on the config naming, because we'd
    probably still want a knob for "how much work".

  - I wondered if we could give a better answer than "these two are
    different" based on a partial walk. But certainly not in the general
    case. E.g., imagine:

      ... -- master -- A -- B -- ... -- Y -- Z -- origin/master

    If we walk back from origin/master and give up somewhere in the
    middle, we can't say anything intelligent about the relationship.

-Peff

  reply	other threads:[~2017-12-24 14:33 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-21 19:09 [PATCH v2 0/5] Add --no-ahead-behind to status Jeff Hostetler
2017-12-21 19:09 ` [PATCH v2 1/5] core.aheadbehind: add new config setting Jeff Hostetler
2017-12-21 20:21   ` Igor Djordjevic
2017-12-21 20:43   ` Jonathan Nieder
2017-12-22 18:21     ` Junio C Hamano
2017-12-24 14:33       ` Jeff King [this message]
2017-12-27 17:41         ` Junio C Hamano
2018-01-04 19:26           ` Jeff King
2018-04-03  9:54             ` Lars Schneider
2018-04-03 10:18               ` Ævar Arnfjörð Bjarmason
2018-04-03 11:39                 ` Derrick Stolee
2018-04-03 13:47                   ` Jeff Hostetler
2018-01-02 21:54     ` Jeff Hostetler
2018-01-02 22:17       ` Jonathan Nieder
2017-12-21 19:09 ` [PATCH v2 2/5] stat_tracking_info: return +1 when branches are not equal Jeff Hostetler
2017-12-21 20:48   ` Jonathan Nieder
2017-12-21 19:09 ` [PATCH v2 3/5] status: add --[no-]ahead-behind to porcelain V2 output Jeff Hostetler
2017-12-21 20:57   ` Jonathan Nieder
2017-12-21 19:09 ` [PATCH v2 4/5] status: update short status to use --no-ahead-behind Jeff Hostetler
2017-12-21 19:09 ` [PATCH v2 5/5] status: support --no-ahead-behind in long format Jeff Hostetler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171224143318.GC23648@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@jeffhostetler.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jeffhost@microsoft.com \
    --cc=jrnieder@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).