Add groups for commands in help

[aawsome]

Adds the possibility to group the commands in the help message.

closes #836 closes #1271

[jharshman]

@aawsome I think this is a good addition. It's something I can put on the roadmap after 1.0.0 is released.

[CLAassistant]

All committers have signed the CLA.

[mhewedy]

Any updates on this? or any workarounds exist?

[github-actions[bot]]

This PR is being marked as stale due to a long period of inactivity

[aawsome]

I rebased this PR. Now that 1.0.0 is out, is there anything I can do to get this PR merged?

[itskingori]

@aawsome Maybe we can nudge @jharshman for some visibility. I think should be able to provide some direction.

[umarcor]

@aawsome would you mind adding some tests for this feature?

[aawsome]

Added some tests. Almost all new code is covered by these tests.

The exception is AddCommandGroup when helpCommand is manually set. (In this case most people would anyway directly specify the Group within the Command definition)

[aawsome]

Is there anything I can do to help getting this PR merged?

[nacx]

This has been open for a while and would be pretty nice to have this merged. Any chance anyone could have a look at it?

[itskingori]

@aawsome Branch has conflicts. Could you rebase? So that if it's ready by the time @jharshman has a another look?

[aawsome]

@aawsome Branch has conflicts. Could you rebase? So that if it's ready by the time @jharshman has a another look?

is rebased.

[yuvalsosman]

Hey, Any updates regarding this feature?

[umarcor]

@yuvalsosman, see #1496.

[MichaelMure]

Also close https://github.com/spf13/cobra/issues/1271

[github-actions[bot]]

This PR is being marked as stale due to a long period of inactivity

[codyaray]

What's blocking this from being merged?

[aawsome]

From my side, I'm fine with getting this merged. Actually realized that this PR is now waiting now for more than two years - that's quite some time...

Anyhow, if there is anything I can do, please tell me!

[itskingori]

@jpmcb Any chance you could look at this?

[jpmcb]

Hi all - thanks for the ping, sorry this got so stale!

This looks like something the community has alot of support for, so let's get this in on the next release! 🌠 Will plan to review and merge soon

[yuvalsosman]

Hi, Happy to see this PR is going to be released soon, do you have some estimation of when this feature will be available?

[RainbowMango]

@aawsome Seems we are ready to go, but you might have to solve the conflicts first.

[aawsome]

I rebased and fixed the test that was failing bacause of the automatically-added completion command.

This PR should be now ready for merging.

[ssoroka]

@marckhouzam @jpmcb Sorry to ping, but can we get this merged now?

[umarcor]

@ssoroka see #1626.

[aawsome]

Sorry if this sounds rude.

This PR is now open for 2 1/2 years. I always almost immediately answered to any question or request. Which was in last history mostly rebasing because of code changes in master. This PR was on the roadmap for 1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0, 1.5.0 (or maybe not for all, but I'm not connected to release planing). Sorry, but this is really annoying!

I'm not working seriously with go for about one year now. This PR is still mergeable. @maintainers: Please decide if you like to merge this PR or close it if not. When the next request for rebasing comes I might simply close it instead of investing (most likely wasted) work into this PR.

[fruitbutt]

@marckhouzam @jpmcb adding to the next milestone has occurred numerous times over the 2.5 years this PR has been open. Many of us would like to see this merged so we can stop maintaining forks, and or ugly templating hacks.

[umarcor]

@fruitbutt see https://github.com/spf13/cobra/blob/main/MAINTAINERS. You might want to ping maintainers listed as non-inactive.

[jpmcb]

Hi all - I'm sorry (again) this PR has gotten stale and I understand your frustration; I really do. I've been trying now for years to get the different places I've worked at to support me and my work for this extremely important open source project.

But, long story short, it all comes down to time; I just have no time to support this project on my own and the companies I've worked for are not interested in allocating any of my time to cobra. But it often feels like if I don't, no one else will, and I deeply fear what could happen if this project falls into disarray. If you didn't know already, cobra is a core dependency in Kubernetes, Helm, Tanzu, Cluster API, Linkerd, Grafana, Istio, etc. etc. and sits at a really important intersection of the Go software supply chain. This is generally why my posture towards new changes is a hesitant one.

So, I give corba what little extra time I have in order to ensure we don't have another faker.js situation on our hands.

Please don't take your frustration out on the maintainers; we are doing our best with what few resources we have but we understand how frustrating this is for the Go community. If we should be frustrated at anyone, it's the endless number of companies that are more than happy to consume these open source libraries while not giving back.

---

I will make this a priority for the next release which I hope to cut within the next few weeks. Thanks all.

[umarcor]

Maybe not introducing any relevant change for years in order to satisfy the needs of all those big companies gave the idea that they don't need to care about this project, because maintainers will take care of gatekeeping potential problems (even in development). I don't mean John's employers only, since this was happening far before he joined the project. Should the project evolve as an open source project which is not funded by any of those companies, maybe they would understand the need to do so.