git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Philippe Blain <levraiphilippeblain@gmail.com>
To: Taylor Blau <me@ttaylorr.com>,
	Abhradeep Chakraborty via GitGitGadget  <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Philip Oakley <philipoakley@iee.email>,
	Junio C Hamano <gitster@pobox.com>,
	Abhradeep Chakraborty <chakrabortyabhradeep79@gmail.com>
Subject: Re: [PATCH v4] builtin/remote.c: teach `-v` to list filters for promisor remotes
Date: Mon, 9 May 2022 13:01:48 -0400	[thread overview]
Message-ID: <54aee42d-fe78-eef1-a371-7ca310a9319f@gmail.com> (raw)
In-Reply-To: <Ynk0mADTSJU/xVUd@nand.local>

Hi Taylor,

Le 2022-05-09 à 11:34, Taylor Blau a écrit :
> On Mon, May 09, 2022 at 11:32:48AM +0000, Abhradeep Chakraborty via GitGitGadget wrote:
>> From: Abhradeep Chakraborty <chakrabortyabhradeep79@gmail.com>
>>
>> `git remote -v` (`--verbose`) lists down the names of remotes along with
>> their URLs. It would be beneficial for users to also specify the filter
>> types for promisor remotes. Something like this -
> 
> This version looks like it has addressed many (all?) of the comments
> previously discussed during review. On a quick scan, the code and tests
> look good to my eyes, too.
> 
> But there was a good question raised by Phillip in
> 
>     https://lore.kernel.org/git/ab047b4b-6037-af78-1af6-ad35ac6d7c90@iee.email/
> 
> that I didn't see addressed in your response, which was "why not put
> this behind a new `--show-partial-filter` option"?

I originally opened the issue on GGG that this series adresses.
My justification, and asnwer to that question, is simple:
'git remote -v', for me, is a way to ask Git to give me all the information it 
knows about my configured remotes. That's why I thought that it would 
be really nice if partial clones filters would be shown. 

After all, 'git remote' is listed in the 'porcelain' section of the 
Git commands [1], and isn't the goal of declaring commands "porcelain"
that we can make their output more useful to the users without worrying as
much about backwards compatibility than with plumbing commands?

> I share (what I think is) Junio's feeling that having information that
> is readily available from e.g., running "git config --get
> remote.<name>.partialObjectFilter" seems redundant. I could understand
> forcing a user to know the config key's name feels like a hurdle. But
> cluttering the output of `git remote -v` seems like the wrong solution
> to that hurdle.

As I said above, I have 'git rem' (my alias for 'git remote -v') in my muscle
memory and use it when I want to have an outline of my configured remotes.
I think it would be really easier to add the filters info to the existing output.
It's really faster to type than using 'git config', and you do not have to remember
which remote name to query. I think "clutter" is a little strong word here :)

> But I can see where it _would_ be useful. So it would be nice to be able
> to turn the extra output on in those cases, but _only_ those cases, and
> a flag would be a nice way to go about doing that.

If really this topic is blocked by "we do not want to change the default output
of 'git remote -v'", then I agree it would be nice to be able to set 
'remote.showFilters' (or similar) to get such output, I agree.

Or, making 'git remote' act like 'git branch' and accept a second '-v', i.e.
'git remote -vv' would list filters (then I would just adjust my alias :P). 
Then we can outright declare "the output of 'git remote -vv' is subject to 
future changes to show more useful information", or similar, so we do not
have to do the same dance the next time we want to add some other info.

The downside of hiding such new features behing config values or additional flags
is that it really, really limits their discoverability. This is something that I 
often think about and think we should really do better in Git, in general. 
For example, features like 'remote.pushDefault' or the 'diff=*' attribute
for language-aware hunk headers (and funcname-limited log/blame etc) are immensely 
useful, but often even experienced and long-time Git users do not even know they exist, 
because they are not covered in "regular" Git tutorials...

Cheers,

Philippe.

[1] https://git-scm.com/docs/git#Documentation/git.txt-ahrefdocsgit-remotegit-remote1a

  reply	other threads:[~2022-05-09 17:03 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-30 13:19 [PATCH] builtin/remote.c: teach `-v` to list filters for promisor remotes Abhradeep Chakraborty via GitGitGadget
2022-04-30 21:17 ` Junio C Hamano
2022-05-01 15:57   ` Abhradeep Chakraborty
2022-05-01 16:14     ` Junio C Hamano
2022-05-01 19:38       ` Abhradeep Chakraborty
2022-05-02 10:33         ` Philip Oakley
2022-05-02 14:56           ` Abhradeep Chakraborty
2022-05-03 15:20 ` [PATCH v2] " Abhradeep Chakraborty via GitGitGadget
2022-05-04 17:10   ` Junio C Hamano
2022-05-05 14:12     ` Abhradeep Chakraborty
2022-05-07 14:20   ` [PATCH v3] " Abhradeep Chakraborty via GitGitGadget
2022-05-08 15:33     ` Philippe Blain
2022-05-09 16:29       ` Junio C Hamano
2022-05-09 16:45         ` Philippe Blain
2022-05-08 15:44     ` Philippe Blain
2022-05-09  9:13       ` Abhradeep Chakraborty
2022-05-09 11:32     ` [PATCH v4] " Abhradeep Chakraborty via GitGitGadget
2022-05-09 15:34       ` Taylor Blau
2022-05-09 17:01         ` Philippe Blain [this message]
2022-05-09 17:52           ` Junio C Hamano
2022-05-13 13:49             ` Abhradeep Chakraborty
2022-05-13 18:37               ` Junio C Hamano
2022-05-16 15:38                 ` Abhradeep Chakraborty
2022-05-09 17:21         ` Abhradeep Chakraborty
2022-05-09 22:22           ` Taylor Blau
2022-05-09 17:44         ` Abhradeep Chakraborty

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=54aee42d-fe78-eef1-a371-7ca310a9319f@gmail.com \
    --to=levraiphilippeblain@gmail.com \
    --cc=chakrabortyabhradeep79@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=me@ttaylorr.com \
    --cc=philipoakley@iee.email \
    /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).