hg rm -A option prints the message of every file in the repo. This is not very user friendly for a big repository with thousands of files. So enabling this feature only when run in --verbose mode (hg rm -Av)
- Group Reviewers
- rHG7a58608281dd: remove: print message for each file in verbose mode only while using `-A` (BC)
Thank you for the proposed change. Does --quiet work for you?
I don't think I necessarily agree with the premise here. I think the only way every file in the repo is printed is if you delete every file first. Many file operations like add, remove/forget, and addremove all follow the style of quiet if files are explicitly named, and verbose for inexact matches. I've come to rely on that to catch mistakes when I'm not explicit about file paths. I'm not sure if it's worse to dump a ton of output to the screen, or not consistently follow the rules.
I'm sure others will chime in, but in the meantime, there's an inline comment too.
Should ui.verbose be nested inside the elif instead? The -v without -A case would have taken the 'else' case before, so this change seems to affect other things unintentionally.
@mitrandir Oh, sorry, I see what you mean now.
I wonder if the nice thing for people used to the current behavior is to terse the directories that don't have deleted files. That way the message is still there, but the sheer volume is lower. If an entire subtree is excluded, only the highest directory level is mentioned.
not removing dirname/: no deleted files not removing dirname2/: no deleted files not removing dirname3/subdir/filename: file still exists ...
But for just the 'still exists' warnings, I guess I don't feel that strongly. Status can always be checked. I do think the first added ui.verbose check is wrong though.
@pavanpc this might just be me misreading phabricator, but you will want your summary to reflect the overall change, because all of the iterations on a single patch will be queued as a single commit. So maybe something like:
remove: change the extant file warning with -A to verbose output
Otherwise, there’s output for every file in the path on which the operation occurs.
— — — (end of commit message) — — —
See here for formatting requirements: https://www.mercurial-scm.org/wiki/ContributingChanges
Sorry I missed this before, but it looks like the return code is changed based on if this case happens. So the “ret = 1” line needs to happen outside of the ui.verbose check.
@pavanpc Looks pretty good- just a few things that popped up in the last revision.
This will need to be protected by seeing if there are any files in modified + added + clean, like it was before. Otherwise, using -A will always return non zero, even if it succeeded without warning cases. Maybe hoist the 'remaining = ...' line out of the conditional?
Here's the evidence of the exit code problem.
Please avoid unnecessary changes like this. It may seem trivial, but if everyone did it, it would make annotating more of a chore.
I don't see any reason for the glob to go away. I suspect it may have been due to the exit code changing in the next line. In general, be careful about not dropping these. The test runner generally doesn't stick them in when run on anything but Windows, and not having them causes test failures on Windows. It's a work around for Windows printing 'removing d1\a' on this same line.
@lothiraldan I modified a test case for hg rm -A <filename> case where we get the message 'not removing <filename>: file still exists' . For other cases, test cases already exist with 'hg rm -A' and 'hg rm --after' without verbose mode.
Moved the 'remaining ' outside the conditional. Making the ui.verbose check only while adding it to the warnings list
I think this probably violates our BC policy. We could probably stand to add a --quiet for suppressing this output, I suppose.
I'll leave this open for other reviewers to mull over, and if it's still open in a week without comment I'll probably pass final judgement.
If this can't be taken as-is, what about something in tweakdefaults to hide this by default? I just assumed that --quiet already worked, and the problem was that this throws away the other more useful warnings in the non --after case. (Or people don't remember to use --quiet before running it.)
FWIW, I watched someone run hg rm -A on a repo with 67K files on Friday, and that made me much more sympathetic.
I can think of below cases. Could you please check and let me know your thoughts on these?
1. hg rm -A - suppress warnings 2. hg rm -Av - do not suppress warnings (could be helpful for small repos) 3. hg rm -A <file1> <file2> - do not suppress warnings 4. hg rm -A <dir> - What should be the behavior here? What if the directory has thousands of files . May be we can suppress warnings based on number of files in the warnings list, like if len(warnings_list) > 25 suppress warnings ? or always suppress warnings for this case 5. hg rm -Av <dir> - do not suppress warnings
I guess the other case is when -I PATTERN or -X PATTERN are used instead of file names. These will be inexact matches like when a directory is specified. I don’t like the dual behavior controlled by how many files are in the directory, because the it will seem inconsistent.
I think "always suppress" is the right thing to do because I would run hg rm -A <dir>
to record deleted files under the directory. In matcher, I think only m.files() needs to
-I PATTERN or -X PATTERN
I see these patterns are not "explicit" files, so won't be warned.