This is an archive of the discontinued Mercurial Phabricator instance.

Differential D3628

status: add default of --terse=u to tweakdefaults (BC)
ClosedPublic

Authored by durin42 on May 20 2018, 1:57 AM.

Details

Reviewers
pulkit
Group Reviewers
hg-reviewers
Commits
rHG6acf41bb8d40: status: add default of --terse=u to tweakdefaults (BC)
Summary

This is in line with both Git and Subversion, and strikes me as a more
humane behavior.

Test output changes are expected once you read test-status.t, and I
feel like we've still got adequate coverage on things.

Diff Detail

Repository
rHG Mercurial
Lint
Lint Skipped
Unit
Unit Tests Skipped

Event Timeline

durin42 created this revision.May 20 2018, 1:57 AM
pulkit accepted this revision.May 20 2018, 4:06 PM
Closed by commit rHG6acf41bb8d40: status: add default of --terse=u to tweakdefaults (BC) (authored by durin42). · Explain WhyMay 20 2018, 4:15 PM
This revision was automatically updated to reflect the committed changes.
martinvonz added a subscriber: martinvonz.Jun 21 2018, 2:09 PM
martinvonz added inline comments.
tests/test-status.t
112–113

We had a more extreme case of "entire working directory is untracked" in our internal tests. It was something like this

$ dir=foo/bar/baz/qux
$ mkdir -p $dir
$ cd $dir
$ echo stuff > file
$ hg st
? file

After this patch (we have tweakdefaults turned on internally), the output is instead this:

$ hg st
../../../../

It's correct, but it's much less readable than the old output. Git does the same thing (it also shows ../../../../), btw.

Maybe we shouldn't terse-ify the files in the current working directory? I understand how treating the working directory differently is not very appealing. Note that with both hg and git, if you add a file in the root directory of an empty repo, then the filename will still be printed (it doesn't just say .).

Consider an empty repo with these paths:

dir/subdir/subdir/a
dir/subdir/b
c

If you're in the root directory, I think we all expect to get this:

? dir/
? c

How about when you're in dir/subdir? We currently get this:

? ../
? ../../c

Perhaps it's better to display this?

? subdir/
? b
? ../../c

That seems consistent with not abbreviating the root directory's entries to just '.'.

It still gets weird when you're in dir/subdir/subdir/. Should we show this?

? a
? ../b
? ../../../c

Thoughts?

durin42 added inline comments.Jun 25 2018, 9:14 AM
tests/test-status.t
112–113

Yeah, that sounds reasonable. I think in general the tersed behavior is better, but this is an annoying edge case. Could you at least send a patch that introduces a "we'd rather we saw this output?" kind of test?

pulkit added inline comments.Jun 25 2018, 10:19 AM
tests/test-status.t
112–113

The proposed change sounds good to me. I haven't looked yet how this can be plugged into current implementation but I feel this won't be hard.

Revision Contents
Changeset List

PathPackages
Mmercurial/ui.py (2 lines)
Mtests/test-status.t (21 lines)

Diff 8836

mercurial/ui.py

[commands] [commands]
# Make `hg status` emit cwd-relative paths by default. # Make `hg status` emit cwd-relative paths by default.
status.relative = yes status.relative = yes
# Refuse to perform an `hg update` that would cause a file content merge # Refuse to perform an `hg update` that would cause a file content merge
update.check = noconflict update.check = noconflict
# Show conflicts information in `hg status` # Show conflicts information in `hg status`
status.verbose = True status.verbose = True
# Collapse entire directories that contain only unknown files
status.terse = u
[diff] [diff]
git = 1 git = 1
showfunc = 1 showfunc = 1
""" """
samplehgrcs = { samplehgrcs = {
'user': 'user':

tests/test-status.t

combining patterns with root and patterns without a root works combining patterns with root and patterns without a root works
$ hg st a/in_a re:.*b$ $ hg st a/in_a re:.*b$
? a/in_a ? a/in_a
? b/in_b ? b/in_b
tweaking defaults works tweaking defaults works
$ hg status --cwd a --config ui.tweakdefaults=yes $ hg status --cwd a --config ui.tweakdefaults=yes
? 1/in_a_1 ? .
? in_a ? ../b/
martinvonzUnsubmitted
Not Done

We had a more extreme case of "entire working directory is untracked" in our internal tests. It was something like this

$ dir=foo/bar/baz/qux
$ mkdir -p $dir
$ cd $dir
$ echo stuff > file
$ hg st
? file

After this patch (we have tweakdefaults turned on internally), the output is instead this:

$ hg st
../../../../

It's correct, but it's much less readable than the old output. Git does the same thing (it also shows ../../../../), btw.

Maybe we shouldn't terse-ify the files in the current working directory? I understand how treating the working directory differently is not very appealing. Note that with both hg and git, if you add a file in the root directory of an empty repo, then the filename will still be printed (it doesn't just say .).

Consider an empty repo with these paths:

dir/subdir/subdir/a
dir/subdir/b
c

If you're in the root directory, I think we all expect to get this:

? dir/
? c

How about when you're in dir/subdir? We currently get this:

? ../
? ../../c

Perhaps it's better to display this?

? subdir/
? b
? ../../c

That seems consistent with not abbreviating the root directory's entries to just '.'.

It still gets weird when you're in dir/subdir/subdir/. Should we show this?

? a
? ../b
? ../../../c

Thoughts?

martinvonz: We had a more extreme case of "entire working directory is untracked" in our internal tests. It…
durin42AuthorUnsubmitted
Not Done

Yeah, that sounds reasonable. I think in general the tersed behavior is better, but this is an annoying edge case. Could you at least send a patch that introduces a "we'd rather we saw this output?" kind of test?

durin42: Yeah, that sounds reasonable. I think in general the tersed behavior is better, but this is an…
pulkitUnsubmitted
Not Done

The proposed change sounds good to me. I haven't looked yet how this can be plugged into current implementation but I feel this won't be hard.

pulkit: The proposed change sounds good to me. I haven't looked yet how this can be plugged into…
? ../b/1/in_b_1
? ../b/2/in_b_2
? ../b/in_b
? ../in_root ? ../in_root
$ HGPLAIN=1 hg status --cwd a --config ui.tweakdefaults=yes $ HGPLAIN=1 hg status --cwd a --config ui.tweakdefaults=yes
? a/1/in_a_1 (glob) ? a/1/in_a_1 (glob)
? a/in_a (glob) ? a/in_a (glob)
? b/1/in_b_1 (glob) ? b/1/in_b_1 (glob)
? b/2/in_b_2 (glob) ? b/2/in_b_2 (glob)
? b/in_b (glob) ? b/in_b (glob)
? in_root ? in_root
$ HGPLAINEXCEPT=tweakdefaults hg status --cwd a --config ui.tweakdefaults=yes $ HGPLAINEXCEPT=tweakdefaults hg status --cwd a --config ui.tweakdefaults=yes
? 1/in_a_1 (glob) ? .
? in_a ? ../b/
? ../b/1/in_b_1 (glob)
? ../b/2/in_b_2 (glob)
? ../b/in_b (glob)
? ../in_root (glob) ? ../in_root (glob)
relative paths can be requested relative paths can be requested
$ cat >> $HGRCPATH <<EOF $ cat >> $HGRCPATH <<EOF
> [commands] > [commands]
> status.relative = True > status.relative = True
> EOF > EOF
? in_root ? in_root
if relative paths are explicitly off, tweakdefaults doesn't change it if relative paths are explicitly off, tweakdefaults doesn't change it
$ cat >> $HGRCPATH <<EOF $ cat >> $HGRCPATH <<EOF
> [commands] > [commands]
> status.relative = False > status.relative = False
> EOF > EOF
$ hg status --cwd a --config ui.tweakdefaults=yes $ hg status --cwd a --config ui.tweakdefaults=yes
? a/1/in_a_1 ? a/
? a/in_a ? b/
? b/1/in_b_1
? b/2/in_b_2
? b/in_b
? in_root ? in_root
$ cd .. $ cd ..
$ hg init repo2 $ hg init repo2
$ cd repo2 $ cd repo2
$ touch modified removed deleted ignored $ touch modified removed deleted ignored
$ echo "^ignored$" > .hgignore $ echo "^ignored$" > .hgignore