Sun, 09 Jul 2017 16:38:04 -0400 test-subrepo: demonstrate a status problem when merge deletes a file
Matt Harbison <matt_harbison@yahoo.com> [Sun, 09 Jul 2017 16:38:04 -0400] rev 33366
test-subrepo: demonstrate a status problem when merge deletes a file At the interactive update prompt, if (c) is chosen and then followed by `hg rm`, both `status -R` and `status -S` show the file as 'R', and `files -R` shows no files (OK, because explicitly removed files aren't supposed to be listed). If `rm` follows selecting (c), then both flavors of `status` list the file as '!', and `files -R` lists the missing file. So somehow, the (d) option has followed a third path.
Sun, 09 Jul 2017 16:13:30 -0400 subrepo: make the output references to subrepositories consistent
Matt Harbison <matt_harbison@yahoo.com> [Sun, 09 Jul 2017 16:13:30 -0400] rev 33365
subrepo: make the output references to subrepositories consistent Well, mostly. The annotation on subrepo functions tacks on a parenthetical to the abort message, which seems reasonable for a generic mechanism. But now all messages consistently spell out 'subrepository', and double quote the name of the repo. I noticed the inconsistency in the change for the last commit.
Sun, 09 Jul 2017 02:55:46 -0400 subrepo: consider the parent repo dirty when a file is missing
Matt Harbison <matt_harbison@yahoo.com> [Sun, 09 Jul 2017 02:55:46 -0400] rev 33364
subrepo: consider the parent repo dirty when a file is missing This simply passes the 'missing' argument down from the context of the parent repo, so the same rules apply. subrepo.bailifchanged() is hardcoded to care about missing files, because cmdutil.bailifchanged() is too. In the end, it looks like this addresses inconsistencies with 'archive', 'identify', blackbox logs, 'merge', and 'update --check'. I wasn't sure how to implement this in git, so that's left for someone more familiar with it.
Sun, 09 Jul 2017 02:46:03 -0400 archival: flag missing files as a dirty wdir() in the metadata file (BC)
Matt Harbison <matt_harbison@yahoo.com> [Sun, 09 Jul 2017 02:46:03 -0400] rev 33363
archival: flag missing files as a dirty wdir() in the metadata file (BC) Since the identify command adds a '+' for missing files, it's reasonable that this does too. Perhaps the node field's hex value should be p1+p2 for merges?
Sun, 09 Jul 2017 00:53:16 -0400 cmdutil: simplify the dirty check in howtocontinue()
Matt Harbison <matt_harbison@yahoo.com> [Sun, 09 Jul 2017 00:53:16 -0400] rev 33362
cmdutil: simplify the dirty check in howtocontinue() This is equivalent to the previous code. But it seems to me that if the user is going to be prompted that a commit is needed, missing files should be ignored, but branch and merge changes shouldn't be.
Sun, 09 Jul 2017 00:23:03 -0400 blackbox: simplify the dirty check
Matt Harbison <matt_harbison@yahoo.com> [Sun, 09 Jul 2017 00:23:03 -0400] rev 33361
blackbox: simplify the dirty check Same idea (and possibly incorrect behavior) as the previous commit.
Sun, 09 Jul 2017 00:19:03 -0400 identify: simplify the dirty check
Matt Harbison <matt_harbison@yahoo.com> [Sun, 09 Jul 2017 00:19:03 -0400] rev 33360
identify: simplify the dirty check This is equivalent to the previous code, but it seems better to be explicit about what aspects of dirty are being ignored. Perhaps they shouldn't be, since the help text says 'followed by a "+" if the working directory has uncommitted changes'. Both merges and branch changes are committable, even if the files are unchanged. Additionally, this will make the `identify` command notice missing subrepo files, once subrepos are taught to look for missing files.
Sun, 09 Jul 2017 00:05:31 -0400 tests: tweak the subrepo dirty state tests
Matt Harbison <matt_harbison@yahoo.com> [Sun, 09 Jul 2017 00:05:31 -0400] rev 33359
tests: tweak the subrepo dirty state tests This is a continuation of 439b4d005b4a. I overlooked that blackbox logs also have a dirty marker. Also, the `hg update --check` test was updating to a revision where the deleted file wasn't tracked, which is why status seemed to show the deleted file was restored.
Sun, 09 Jul 2017 23:01:11 -0700 match: combine regex code for path: and relpath:
Martin von Zweigbergk <martinvonz@google.com> [Sun, 09 Jul 2017 23:01:11 -0700] rev 33358
match: combine regex code for path: and relpath: The regexes for path: and relpath: patterns are the same (since the paths have already been normalized at the point we create the regexes). I don't think the "if pat == '.'" will have any effect relpath: because relpath: patterns will have the root directory already normalized to '' by pathutil.canonpath() (unlike path:, for which the root gets normalized to '.' by util.normpath()).
Sun, 09 Jul 2017 22:53:02 -0700 match: remove unnecessary '^' from regexes
Martin von Zweigbergk <martinvonz@google.com> [Sun, 09 Jul 2017 22:53:02 -0700] rev 33357
match: remove unnecessary '^' from regexes The regexes are passed to re.match(), which matches against the beginning of the input, so the '^' doesn't do anything. Note that unrooted patterns, such as globs and regexes from .hgignore are instead achieved by adding '.*' to the expression given by the user. (That's unless the user's expression started with '^', in which case the '.*' is not added, perhaps to keep the regex cleaner?)
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip