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.

@mharbison72: the problem is that hg rm -A prints a line for every file in the repo even if you didn't touch anything. With a clean working directory in a repo with 10k files, 10k lines will be printed. The lines look like:

not removing <filename>: file still exists

@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.

@mharbison72 Thank you for reviewing this diff. The diff checks for "not removing <filename>: file still exists". I have removed the ui.verbose check from elif.

@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

@mharbison72 Thank you for suggesting that. I have updated the phabricator titile.

@pavanpc Looks pretty good- just a few things that popped up in the last revision.

Looks good to me, thanks.

Could we have a test for hg rm -A without the verbose mode?

@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.

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.

@durin42: I'd say that listing *all the files in the repo* when you run hg rm -A should be considered a bug. This can't possibly be the intended behavior. Also: running hg rm -A without a file argument is not even covered by any testcase.

@yuja @mitrandir

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 think that the cases mentioned by you are right :) In case of directory I'd prefer so suppress warns. What do you think @yuja ?

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.

In D1336#23872, @pavanpc wrote:

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

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
be warned.

-I PATTERN or -X PATTERN

I see these patterns are not "explicit" files, so won't be warned.

@yuja Thank you for your input. Now, warnings are suppressed for the directory case. Also, I have added test cases for the above cases.

@durin42: I think it should be as good as possible BC-wise. What do you think?