-
Notifications
You must be signed in to change notification settings - Fork 38
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
git: format only files that changed #311
Comments
If the modified time has not changed when compared with the git index we do not emit the file for processing. This allows users to introduce treefmt to a repository without suffering an initial large formatting commit. Instead, files can be formatted incrementally as they are changed. Closes #311 Signed-off-by: Brian McGee <brian@bmcgee.ie>
If the modified time has not changed when compared with the git index we do not emit the file for processing. This allows users to introduce treefmt to a repository without suffering an initial large formatting commit. Instead, files can be formatted incrementally as they are changed. Closes #311 Signed-off-by: Brian McGee <brian@bmcgee.ie>
Be sure to take into account the ideas from #78 |
Enabling incremental adoption is a noble goal! I have a couple of thoughts on the scheme proposed here:
I don't actually know how to fix either of these problems. Thoughts:
|
Sorry for the possibly-negative sounding wall of text. I'm skeptical that the scheme proposed here would actually be useful for the large, active projects. That may not be the goal of this feature, though, in which case, feel free to ignore my comment! |
I am okay with re-formatting a whole file, and I don't think we should ever get into trying to format files partially. However, the issue you highlighted about CI is complicated, which I had yet to consider. There's no suitable mechanism I can think of that would allow CI to verify that formatting was applied correctly on a given branch unless we make @zimbatm thoughts? |
Whether you should do a treewide format-everything commit or this kind of slow burn is a matter of preference. In nixpkgs, people are already reformatting things they touch to nixfmt-rfc-style. Regarding unformatted files slipping by, this is the same currently. You can create an intermediate commit that isn't formatted, and GitHub Actions will not be the wiser. But that's an issue with GHA. Gerrit can run CI on every commit. The last thing that remains is getting the list of files that changed. For this, the CI should pass a |
That makes sense. We should name/document in so that it's clear it's only needed for when treefmt is being used in "transitional mode". On projects that are using treefmt to fully enforce formatting, there's no need to use this.
Neat! Is that an additional "feature" for us to build? Specifically: enforce formatting on the most recent commit? Or do you see this as a specific example of how to use I still suspect that having an explicit, version controlled "burndown list" of files that are "grandfathered" into their current formatting style would be preferable. My current thinking:
|
For the record, here's evidence that large projects adopting auto-formatting are interested in partial formatting: NixOS/nixfmt#223. |
🤔 If a walker is capable of identifying line ranges that have changed within a file, we could allow them to set that on We could invoke the formatter once per line range, assuming a formatter API that looks something like We would have to ensure we do this in a sequential manner per file, one range at a time. That would be an adjustment to the batch key / scheduler, but I don't think a difficult one. This is just spit balling. Are there any examples of formatters which allow range formatting, it would be good to get a sense of what their apis look like. Do they tend to accept multiple ranges in one invocation or is it a single range per invocation? Multiple ranges per invocation means less changes to the scheduling and more work on how we pass parameters to the formatter. |
Just want to briefly chime in: In Nixpkgs we currently enforce formatting for new files and files that are already formatted, which makes sure that the number of unformatted files can only decrease and doesn't require any separate tracking. Check out NixOS/nixpkgs#326407 |
Is your feature request related to a problem? Please describe.
When introducing a "dirty" project to treefmt, it can create a lot of code churn as files that previously weren't formatted are now getting changed. You often end up with a fat commit that formats the whole repo and breaks
git blame
.Describe the solution you'd like
When the file backend is git, only format the untrack and changed files by default.
Add a
--all-files
flag to override that default.Describe alternatives you've considered
Additional context
The text was updated successfully, but these errors were encountered: