[Bug 5785] New: hg up -C <file> should always fail.

[mercurial-bugs at mercurial-scm.org]

https://bz.mercurial-scm.org/show_bug.cgi?id=5785

            Bug ID: 5785
           Summary: hg up -C <file> should always fail.
           Product: Mercurial
           Version: 4.1.2
          Hardware: Macintosh
                OS: Mac OS
            Status: UNCONFIRMED
          Severity: bug
          Priority: wish
         Component: Mercurial
          Assignee: bugzilla at mercurial-scm.org
          Reporter: hg at andreww.nomau.net
                CC: mercurial-devel at mercurial-scm.org

Summary:

"hg up -C file" fails with an error, unless "file" is the name of a revision.

(Or, to put it another way, operations that modify files should always require
-r when referring to revisions, to avoid confusion between commands that
operate on files and commands that operate on the repository but also change
files.)


Scenario:

Repository with the following changes:
M a/file1.txt
M b/file2.txt

In directory 'b', execute command:

hg up -C .

Expected behaviour:

* Fails, because it's not meaningful to update a subset of a repository.

Actual behaviour:

* Discards all changes to all files without backup

If I instead tried 'hg up -C file.txt', the result would most likely be "No
such revision: file2.txt".


This is due to a confusion between "update" and "revert".  There's significant
overlap between them, in that both make files in the working directory match a
particular revision (among other things, in the case of update).

Here's the problem:

These have identical behaviour: make all working files match the current
repository
* hg up -C
* hg revert [--no-backup]

These do not:
* hg up -C .
* hg revert [--no-backup] .

"hg revert ." makes all working files in the current directory match the
current repository
"hg up -C ." makes all working files in the *repository* match the current
repository

Adding a "." argument to revert applies to files (which is consistent with most
other commands).  If I want to specify a revision, I use "-r REV".

Adding a "." argument to update doesn't change the semantics at all (the
default is the current revision, or ".").  I can also specify a revision using
"-r REV", but the "-r" is optional.

We start with two functionally identical commands, add the same argument as a
qualifier, and get different behaviour.  This is covered if one reads the
documentation closely, but is dangerous from a "try it and see" perspective.

This confusion wouldn't be a noticeable problem if "update" was a rare command,
but it's used all the time. Trying to update a single file should *always*
fail, but instead it fails *unless* the "filename" can be interpreted as a
revision.

IMO, operations that affect files should always require -r when referring to
revisions, even when files are not a legal argument (e.g. update, graft,
merge).

Alternative: modify "up -C" so that it ONLY works when the underlying revision
changes.  Force users to use of "hg revert" to discard changes without changing
revision, thus training users not to use "hg up -C" as a synonym for "hg
revert".

Related question: is the implicit "no backup" of "hg up -C" a feature or a bug?
 Is there a reason for "hg up -C" to not by default create .orig files of any
files that are replaced?  I notice there is no way to cause "hg up" to
force-change but with backup.

-- 
You are receiving this mail because:
You are on the CC list for the bug.