From: Junio C Hamano <gitster@pobox.com>
To: Ben Knoble <ben.knoble@gmail.com>
Cc: "Yury Norov" <ynorov@nvidia.com>,
"Yury Norov" <yury.norov@gmail.com>,
git@vger.kernel.org, "Thiago Perrotta" <tbperrotta@gmail.com>,
"Philippe Blain" <levraiphilippeblain@gmail.com>,
"Rubén Justo" <rjusto@gmail.com>,
linux-kernel@vger.kernel.org, Codex <codex@openai.com>
Subject: Re: [PATCH] completion: complete paths for git send-email
Date: Wed, 22 Jul 2026 08:32:42 -0700 [thread overview]
Message-ID: <xmqq4ihrt4yt.fsf@gitster.g> (raw)
In-Reply-To: <C9564DC6-6B68-46CA-A339-1A1774AFA7C0@gmail.com> (Ben Knoble's message of "Wed, 22 Jul 2026 06:29:43 -0400")
Ben Knoble <ben.knoble@gmail.com> writes:
>> As to the tests, using 40-hex is misleading, and 0-branch as you
>> said would be sufficient to reproduce and demonstrate the issue, and
>> that your code change fixes it.
>>
>> Ben, anything I missed?
>>
>> Thanks.
>
> Not from my end, though SZEDER’s review merits some thinking.
I agree that presenting both refs and paths cleanly will require a
much better structure than a flat list. I also agree that hiding
paths when we have ref matches may give us a cleaner layout than
mixing them alphabetically into a single, flat list. While I am
still not convinced it is the best way, at least that is the
principle current completion implementations use for other commands,
and it makes sense to model the updated completion for send-email
after it.
That said, since I never feed refs to send-email myself, 'if we have
matches with refs, do not show paths at all' rule makes send-email
completion completely useless, at least to me.
> Traveling the next week+; replies may be slower (than usual, hah).
Have a great trip, and have fun!
Thanks.
next prev parent reply other threads:[~2026-07-22 15:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-19 13:44 [PATCH] completion: complete paths for git send-email Yury Norov (NVIDIA)
2026-07-19 17:04 ` Junio C Hamano
2026-07-21 12:49 ` D. Ben Knoble
2026-07-21 17:09 ` Junio C Hamano
2026-07-21 18:03 ` Yury Norov
2026-07-21 19:22 ` Junio C Hamano
2026-07-22 10:29 ` Ben Knoble
2026-07-22 15:32 ` Junio C Hamano [this message]
2026-07-21 22:21 ` SZEDER Gábor
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=xmqq4ihrt4yt.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=ben.knoble@gmail.com \
--cc=codex@openai.com \
--cc=git@vger.kernel.org \
--cc=levraiphilippeblain@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rjusto@gmail.com \
--cc=tbperrotta@gmail.com \
--cc=ynorov@nvidia.com \
--cc=yury.norov@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.