-
Notifications
You must be signed in to change notification settings - Fork 348
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FR: Support filename arguments for jj fix
#3800
Comments
I meant to open this a while ago: #3809, which would also address the |
#3857 addressed the issue of fixing a subset of changed files. There's still some room to determine exactly how fixing unchanged files should work. Some possibilities:
I think we probably want this to compose with commands like |
I think that's what I'd vote for. It seems rare to need the more generic version, and it seems it should be possible to achieve by two calls instead ( |
I commented in #3808 (comment) to 1) propose that separating per-file and per-working-copy fixes for I'm not necessarily opposed to configuring the passing of filenames to
In this case, it seems appropriate to not rely on making In my experience doing codebase-wide formats and refactorings, I often want to check the result in a non-automated way afterwards, to make sure that the scope wasn't unexpectedly broad or narrow, or there weren't any obvious egregious issues. In those cases, it doesn't benefit me to put it in a subcommand that's meant for automated fixes, except in that it was possibly easier to find a good command invocation. (It might not be anyways; it's probably much easier for me to run |
Problem:
Users of
jj fix
are likely to sometimes want to only fix subsets of changed files, or to fix specific unchanged files.Solution:
Use positional arguments to create a matcher for use when diffing commits to choose which paths to fix:
jj fix -s <rev> <file...>
Alternatives:
Tweaking the
jj fix
configuration on a per-command basis seems too cumbersome, although this depends on how frequently a particular project would want to format a subset of files, and on the complexity of itsjj fix
configuration.Context:
Possible motivations for using this feature include:
jj fix
configuration, which might be more work than it's worth for infrequent issues.jj fix
configuration to always avoid the file.One debatable aspect is whether users should be able to fix unchanged files by listing their names in the command.
hg fix
does this by default. We may want to require an additional flag to enable this behavior:jj fix -s <rev> <file> --fix-unchanged-files
. An example use case is generating a commit that updates the formatting of some files to agree with the current version of a formatter, so that descendant commits won't become cluttered with those formatting-only changes.An open question is how exactly to use copy/move information. Is it reasonable to assume that the user wants to format the file in revisions where it has moved to a new path? Is it reasonable to format multiple copies of a file when the user only specified one path?
The specific command
hg fix .
has proven to be a mild foot gun at Google, because it looks a lot likehg fix -r .
. Fortunately,jj fix
shouldn't have that issue, due to the revset syntax using@
instead of.
. So, we can probably allowjj fix .
to fix everything in the directory, as long as it has some output or a progress bar to make it obvious when the user has accidentally asked it to format an impractically large number of files (which is less of a problem for smaller repos).The text was updated successfully, but these errors were encountered: