-
Notifications
You must be signed in to change notification settings - Fork 352
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
Implement hacky variant of jj purge
#4171
base: main
Are you sure you want to change the base?
Conversation
If we plan to turn "files too large" error into warning (either by default, or by command-line flag), it makes sense that Regarding the UI, I don't think Regarding let stat = locked_wc.snapshot();
let matcher = if args.untracked_large_files {
FilesMatcher::new(stat.files_too_large);
} else {
EverythingMatcher // all untracked files will be purged?
};
locked_wc.purge(&matcher); |
1895759
to
3154e5e
Compare
Snapshot of I can change it to struct Snapshotresults{
tree_id: MergedTreeId,
stats: SnapshotStats
} with
|
Sounds good.
I think it's better to have the callers explicitly get the tree id and the stats. See https://doc.rust-lang.org/std/ops/trait.Deref.html#when-to-implement-deref-or-derefmut |
3154e5e
to
4f861bd
Compare
@yuja @martinvonz I'm not sure what to do when we can't snapshot files.
Also, maybe UPD. I forgot about deleting ignored files. But it seems like backend wouldn't know about them anyway |
Yes, printing a warning and a hint and then proceeding sounds good to me. However, I think there's some risk of losing data then. In particular, I think we would lose the file in this scenario:
We are careful not to overwrite files when updating between commits, but only if the file was added. If the file existed in the old commit (i.e. the working-copy commit on top of Y in this case, which was snapshotted at the start of I suppose we could be more careful in this case and not update files if their mtime etc don't match our expectation. Oh, I suppose we can also fix it for the large-files case by making the snapshotting remove files from the snapshotted tree (but not from the working copy) if they are too large. I think that would make logical sense too.
Maybe that will need to be implemented by a different function on the |
If the file has already been tracked, I think it will be snapshotted at 4. It might be good to disable working-copy mutation if snapshot emitted a warning. |
It's a hacky variant to retrieve a list of files that are too large to be snapshotted, but I haven't found a better way to do it. If you think it's acceptable, I can further polish it. Testing it on #3616 (comment) gives this result:
Checklist
If applicable:
CHANGELOG.md