[RFC] download-commands plugin multi-shell feature

[Notarin Steele]

Greetings all,
I am a first time potential contributor, so please bear with me if I
break norm or standard.

I plan to look into contributing to the plugin download-commands.
Specifically I plan to contribute multi-shell awareness/configuration.
However I want to touch bases with the maintainers and request for
comment on the UX of the addition.
Currently there are tabs for the protocol of the git URI, so my
current best ideas are to either:

- Add a dropdown selection box for your shell of choice in the download pane.
- Add a dropdown selection box for your shell of choice in the user
settings pane.
- Compactly display the download commands grouped together by command,
displaying all shells commands in each packed group.

For some context, this was provoked by the adoption of gerrit in a
team. This is the first group that uses windows, and is as well not
quite as shell-savvy across the board as most. We found users having
more difficult onboarding when they were windows users with only
powershell, which led us into having to develop scripting solutions
for them. I as well am inconvenienced as a nushell user, however have
never to this day seen it as cause for change due to it being a simple
`&&` -> `;` change, but nonetheless it compounds with my measured
issue.

Additionally, so I may be more compliant with the expected process, a
couple questions.
Does the maintainer team prefer atomic, change-oriented, or
feature-oriented commits? (should the verbiage be poor, I mean how big
do you want my commits, or how many do you want the feature split
across)
Does the maintainer team prefer I target the master branch?
Is backporting this feature to any major version branches something I
can expect to happen?

Thank you for your time.

[Daniele Sassoli]

Hi Notarin

On Sunday, 19 July 2026 at 23:17:23 UTC+1 424c4...@gmail.com wrote:

Greetings all,
I am a first time potential contributor, so please bear with me if I
break norm or standard.

I plan to look into contributing to the plugin download-commands. 

Specifically I plan to contribute multi-shell awareness/configuration.
However I want to touch bases with the maintainers and request for
comment on the UX of the addition.

Let me start by saying I'm not a maintainer, regardless here are my 2 cents. 

Currently there are tabs for the protocol of the git URI, so my
current best ideas are to either:

- Add a dropdown selection box for your shell of choice in the download pane.
- Add a dropdown selection box for your shell of choice in the user
settings pane.
- Compactly display the download commands grouped together by command,
displaying all shells commands in each packed group.

For some context, this was provoked by the adoption of gerrit in a
team. This is the first group that uses windows, and is as well not
quite as shell-savvy across the board as most. We found users having
more difficult onboarding when they were windows users with only
powershell, which led us into having to develop scripting solutions
for them. I as well am inconvenienced as a nushell user, however have
never to this day seen it as cause for change due to it being a simple
`&&` -> `;` change, but nonetheless it compounds with my measured
issue.

Essentially you're suggesting adding a sort of dropdown that would allow

a user to select different shells, this would in turn update the displayed

download command. If so, this seems sensible to me.

Additionally, so I may be more compliant with the expected process, a
couple questions.
Does the maintainer team prefer atomic, change-oriented, or
feature-oriented commits? (should the verbiage be poor, I mean how big
do you want my commits, or how many do you want the feature split
across)

The smaller the better, but each commit should add value on itself.
 

Does the maintainer team prefer I target the master branch? 

Is backporting this feature to any major version branches something I
can expect to happen?

Yes, I would definitely target master, cherry-picking to previous version

shouldn't then be too hard, depending how invasive the changes are.

 
Overall, seems like an interesting feature.
Do you already have some sort of working prototype?

[Notarin Steele]

I do not, unfortunately.
When I made this post, I attempted to get a developer environment working.
I hold my dev environments to certain standards, and given the build
system Gerrit uses I could not get a development environment I was
satisfied with at the time.
However, I plan to take another shot at it and hope to figure
something out I'm happy with this time.
I also plan to reach out to see if I have any Nix oriented peers in
the Gerrit community, and that will surely help.

> The smaller the better, but each commit should add value on itself.

Could you define value for me? Specifically, by value do you mean:
- Each commit should be a discernable change to the project,
- Each commit should have a effective difference in the softwares behavour,
- Or, what I personally align with the most, each commit should have a
discernable improvement to the repo (worth picking/merging).

Thank you for your feedback by the way! I find this very encouraging
and am hopeful to return with a prototype soon!

[Daniele Sassoli]

On Thursday, 22 October 2026 at 21:54:30 UTC+1 424c4...@gmail.com wrote:

I do not, unfortunately.
When I made this post, I attempted to get a developer environment working.
I hold my dev environments to certain standards, and given the build
system Gerrit uses I could not get a development environment I was
satisfied with at the time.
However, I plan to take another shot at it and hope to figure
something out I'm happy with this time.
I also plan to reach out to see if I have any Nix oriented peers in
the Gerrit community, and that will surely help.

> The smaller the better, but each commit should add value on itself.
Could you define value for me? Specifically, by value do you mean:
- Each commit should be a discernable change to the project,
- Each commit should have a effective difference in the softwares behavour,
- Or, what I personally align with the most, each commit should have a
discernable improvement to the repo (worth picking/merging).

I don't think we have such strict definition, as long as you don't send

everything in one go and you make your best effort to produce incremental commits,

I believe you'll be fine.
I wouldn't overthink this or let it stop you from contributing.
The feature sounds relatively small as well so I wouldn't expect a huge amount of changes.
Maybe first adding the backend parts and then the UI bits is a good split.