I can't speak too much to this as personally I'm not thrilled with the --allow-<something> workflow for the "safe" fixes (which is all we do atm) and so I can't fully speak towards its intent.

I still think it's worthwhile to make this simple change, and I don't have anything to add to the arguments for it.

I think it's now up to you to drive the acceptance process forward. If you don't want to accept this change, then please close the issue instead of leaving it hanging indefinitely.

Keep in mind that we have over 500 issues that need triage and over 100 asking for team input.

To myself I understand and agree that --allow-dirty should be treated like "allow whatever VCS reports as dirty". cargo package --allow-dirty does like that. And cargo fix --allow-dirty before --allow-staged added did that as well.

If I were there in the discussion, I would suggest people to create a temporary commit and run cargo fix. Generally checking in code is cheap and safer than working in staging area. The addition of --allow-staged was also technically a breaking change at that time for workflow that only passed --allow-dirty. I didn't see many discussions about the flag itself and alternatives in #5737 though.

One concern is that the proposal is, again, a breaking change for a pretty odd use case: Only allowing dirty unstaged changes but not staged. I cannot tell who ever wants that though.

Keep in mind that we have over 500 issues that need triage and over 100 asking for team input.

While we do have problems with the huge backlog, I think whoever comes and contributes reasonably should get some rewards. To me, it is a way to prevent the project from drowning in issue backlog and still get helps from old and new friends.

I may be wrong but this proposal seems small enough, so I'll give it a nudge and start an async FCP. No pressure though.

@rfcbot fcp merge

This proposes cargo fix --allow-dirty implies cargo fix --allow-staged.

Arguments:

• The current behavior is that you need to pass both flags if you have changes in both staging area and working directory in a Git repo. Inconvenient.
• Before Add --allow-staged to cargo fix #5943, --allow-dirty in cargo fix implies --allow-staged.
• In cargo package, --allow-dirty implies all changes including in staging area.
• --allow-dirty without --allow-staged is an odd usecase. See the issue description.

Counterarguments:

• It may break somebody's workflow that specifically wants to fix changes in working directory only (the --allow-dirty without --allow-staged use case).
  • cargo fix, especially with --allow-* flags, as a destructive command, is generally used in interactive sessions. It should be extremely rare to break somebody's CI with this change.

Team member @weihanglo has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Eh2406
• @Muscraft
• @Rustin170506
• @arlosi
• @ehuss
• @epage
• @joshtriplett
• @weihanglo

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.