git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>,
	Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH] branch: make -v useful
Date: Sat, 05 Jun 2021 22:18:14 +0200	[thread overview]
Message-ID: <87czt059sn.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <20210605011339.2202-1-felipe.contreras@gmail.com>


On Fri, Jun 04 2021, Felipe Contreras wrote:

> Currently `git branch -v` shows something like "[ahead 10]", but ahead
> of what?
>
> We git experts know ahead of what, but not what that what is set to. Just
> like "[@{upstream}: ahead 10]" would not be particularly useful to
> anyone that doesn't know, or remembers, what @{upstream} is set to.
>
> On the other hand "[master: ahead 10]" is perfectly clear to anyone.
>
> This confusion only gets worse when you see "[ahead 10, behind 100]". Is
> it master? Is it next? Is it
> john/experimental-feature-i-based-my-branch-on?
>
> Inevitably most users will need to know what @{upstream} is.
>
> So let's make `git branch -v` output what is most useful:
>
>   [master]
>
> Before:
>
>   * fc/branch/sane-colors b2489a3735 [ahead 1] branch: make -v useful
>
> After:
>
>   * fc/branch/sane-colors b2489a3735 [master] branch: make -v useful
>

Having applied this patch I find the description a bit confusing. The
example led me to believe that you'd stripped the remote name, so the
common case of "origin/master" would become "master", but instead the
example is from a "fc/branch/sane-colors" branch where your "remote
tracking branch" is actually tracking your *local* master, i.e. "remote
= ."?

Disambiguating that is one of the reasons we prefix with the remote
name, but I'd say it makes for a confusing example in a commit message,
and also if instead of saying:

    branch: make -v useful

It said e.g.:

    branch: reverse the priority of what -v and -vv show

Or something similar to note that it's not "useful" now, but an
opinionated change about what we should show on verbosity level 1 and 2.

In any case, this proposed patch is missing a doc update, in
git-branch.txt we say both:

    When in list mode, show sha1 and commit subject line for each head,
    along with relationship to upstream branch (if any). If given twice,
    print the path of the linked worktree (if any) and the name of the
    upstream branch, as well (see also git remote show <remote>).

And later, for the --track option:

    When creating a new branch, set up branch.<name>.remote and
    branch.<name>.merge configuration entries to mark the start-point
    branch as "upstream" from the new branch. This configuration will
    tell git to show the relationship between the two branches in git
    status and git branch -v.

Both of those need to be updated, and I think the commit messages should
discuss whether we break this promise of having consistent output
between "status" and "branch -v" now.

As for the proposal, I don't use "branch -v" all that much much, so I
don't have strong knee-jerk feelings on it, but just considering it now
I'd think that the current default is a fundamentally better
approximation of what most users would like as a default.

I.e. I think it's fair to say that to the extent that most users have
topic branches they're part of some pull-request workflow where they're
always tracking the one upstream they always care about, usually
origin/master.

The -v output showing the ahead/behind relationship to that branch
without naming it is thus the best use of the limited space we have, and
with a bit more verbosity under -vv we'd show the (usually the same for
all of those) upstream name.

Whereas you are presumably tracking origin/master for some, building on
your own topic (or other people's topics) for another etc., I think that
workflow is much rarer outside of linux.git and git.git, and even for
those most people usually track origin/master with most of their topics.

> An additional benefit is that `git branch -v` is slightly faster: 30ms
> vs. 60ms on my system.

110ms v.s. 5000ms on my system. Lots of old uncleaned-up topics.

For what it's worth I remember some past discussion where it was
discussed to have some human-readable cut-off so instead of saying:

    ahead 2, behind 38741

We'd just fall back on saying "behind lots" once your number of behind
reached some limit (which could dynamically compute as a heuristic based
on repo size, just like the abbrev length)..

  reply	other threads:[~2021-06-05 20:38 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-05  1:13 [PATCH] branch: make -v useful Felipe Contreras
2021-06-05 20:18 ` Ævar Arnfjörð Bjarmason [this message]
2021-06-05 22:35   ` Jeff King
2021-06-07 15:57     ` Felipe Contreras
2021-06-08  6:13       ` Jeff King
2021-06-08  7:17         ` Felipe Contreras
2021-06-08  7:27           ` Jeff King
2021-06-08  8:28             ` Felipe Contreras
2021-06-08  9:06           ` Kerry, Richard
2021-06-08  9:22             ` Felipe Contreras
2021-06-08 11:32               ` Kerry, Richard
2021-06-10  3:26                 ` Felipe Contreras
2021-06-25 15:03                   ` Kerry, Richard
2021-06-25 16:03                     ` Felipe Contreras
2021-06-07 15:28   ` Felipe Contreras
2021-06-07 16:05     ` Ævar Arnfjörð Bjarmason
2021-06-07 18:00       ` Felipe Contreras
2021-06-07 18:37       ` Felipe Contreras

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=87czt059sn.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).