From: Felipe Contreras <felipe.contreras@gmail.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"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: Mon, 07 Jun 2021 13:00:22 -0500 [thread overview]
Message-ID: <60be5eb6923de_39c0a20817@natae.notmuch> (raw)
In-Reply-To: <87h7i94ola.fsf@evledraar.gmail.com>
Ævar Arnfjörð Bjarmason wrote:
> On Mon, Jun 07 2021, Felipe Contreras wrote:
> > Ævar Arnfjörð Bjarmason wrote:
> >> 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
> >
> > I guess that depends on what you consider this patch is doing, why, and how.
> >
> > But I have no problem with your version.
> >
> >> 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.
> >
> > I'm not sure I parsed that correctly, but that's the whole point:
> > verbosity level 1 is not very useful (I'd argue not useful at all).
>
> Maybe, anyway I meant to suggest saying something approaching "reverse
> the order of the data we consider important" instead of the equivalent
> of "make the data useful".
All right, that transmits the message I want to transmit and is less
abrasive, so that's good.
I've updated the title, and in fact changed the whole commit message.
> >> 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.
> >
> > That's an unsupported assumption.
> >
> > As I showed above, most pople track the branch they push to, not
> > origin/master.
> >
> > Google "git branch -v", and you will find mostly official documentation
> > and man pages.
> >
> > Google "git branch -vv", and you will find mostly blog posts, Stack
> > Overflow questions, and cheat sheets.
> >
> > I think the reason why is obvious.
>
> Yes, I stand corrected.
>
> For what it's worth I think one thing to salvage from my ill-informed
> rambling is that I was under that impression because I set
> push.default=upstream.
>
> But yes, with "simple" being the default and refusing to have
> avar/my-topic have an upstream of origin/master my setup is probably not
> the common case.
This is one of the reasons I force myself to have a .gitconfig as clean
as possible; to try to emulate as much as possible the experience of the
typical git user.
Having used push.default=simple for many years now, I find it very
suboptimal. Basically I can't trust git to do the right thing, and I
always specify what to push.
I suspect this is what most users do (unless they have setup upstream
like `git push -u`).
For what it's worth, when there's a difference of opinion in the mailing
list sometimes I create polls in reddit to see what the users think, and
I did for this one:
https://www.reddit.com/r/git/comments/nuf3p5/where_do_you_point_your_upstream_branch_to/
At the moment 13 people say they use origin/master, 11 repo/branch, and
11 say they it's the same thing in their case (e.g. origin/dev).
8 people don't know what an upstream branch is.
> I wonder if this should depend on the setting of push.default, or
> whether we can infer anything at all from that setting. After all you
> can set it to whatever and then either manually do "git push <remote>
> <src>:<dst>" (my usual worklow is just "git push origin HEAD"), or
> manually do the "git rebase origin/master" or whatever in the case where
> your upstream is your own topic branch.
I do have a much better solution that makes everything work for all
configurations, but the patches are not ready yet, and I'm certain will
receive pushback, just like the last time I sent it.
This is the first patch, which I don't think has anything to do with
the rest of the patches, and can very well stand on its own.
Cheers.
--
Felipe Contreras
next prev parent reply other threads:[~2021-06-07 18:01 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
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 [this message]
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=60be5eb6923de_39c0a20817@natae.notmuch \
--to=felipe.contreras@gmail.com \
--cc=avarab@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).