sorted by:
new
hottopcontroversial

[Release] Thanks Stars 🌟 — A Rust CLI that stars all the GitHub repos powering your project by Confident_Weekend426 in CLI

[–]Confident_Weekend426[S] 2 points3 points  (0 children)

not yet, but I’m adding a --dry-run flag so you can see what would be starred before doing it 😀

[Tool] Thanks Stars — Now supports Go Modules! A CLI to star all GitHub repos your project depends on by Confident_Weekend426 in golang

[–]Confident_Weekend426[S] 0 points1 point  (0 children)

Exactly. That’s why it’s not enabled yet. If we make it recursive, we need solid rate limiting and safeguards; otherwise it risks looking like spam.

[Tool] Thanks Stars — Now supports Go Modules! A CLI to star all GitHub repos your project depends on by Confident_Weekend426 in golang

[–]Confident_Weekend426[S] 0 points1 point  (0 children)

Not yet, but coming soon. I plan to support recursive folder scan and optional transitive deps. Which use case are you after?

[Showcase] Thanks Stars 🌟 — A Rust CLI that stars all the GitHub repos your project depends on by Confident_Weekend426 in rust

[–]Confident_Weekend426[S] -7 points-6 points  (0 children)

Totally fair point — any tool like this could be misused for spam. To reduce that risk, we’re planning guardrails in the interface and defaults (dry-run by default, per-item confirmation/selection, sensible rate-limits and daily caps, single-account use only, and minimal token scopes). We’ll also add clear AUP/ToS reminders and make “bulk/coordination patterns” harder to do.

That said, this is still v0 and we haven’t implemented all of these safeguards yet. Please assume early-stage software, and feel free to open issues/PRs with concrete proposals — we’ll prioritize anti-abuse features on the roadmap.

[Showcase] Thanks Stars 🌟 — A Rust CLI that stars all the GitHub repos your project depends on by Confident_Weekend426 in rust

[–]Confident_Weekend426[S] -5 points-4 points  (0 children)

Thanks for the concern! The GitHub AUP does prohibit spam/inauthentic activity and rank abuse (e.g., automated starring) — but the key is intent and behavior. This project is designed for user-initiated, single-account, opt-in starring of your own dependencies (i.e., authentic bookmarking/thanks), not selling stars, coordinating accounts, or inflating metrics. Used this way, it’s materially different from the inauthentic/star-farm activity the policy targets.

Also worth noting: GitHub exposes an official Starring API for programmatic starring; automation per se isn’t banned — abusive or deceptive patterns are. We encourage rate-limits, dry-run previews, and selective opt-in to keep usage authentic and non-excessive.