c0593b622180 changed the styling of the "page_nav" CSS class to use
flexbox to separate elements within the <div>. I didn't realize that
this class was used outside of the links in the header. So this
resulted in incorrectly formatting links in the footer of various
pages. Fix that by introducing a new CSS class that preserves the
old CSS behavior.
If the option is registered, there is already a default value available and
passing a new one is at best redundant. So we issue a deprecation warning in
this case.
(note: there will be case were the default value will not be as simple as what
is currently possible. We'll upgrade the configitems code to handle them in
time.)
We do not have any registered config yet, but we are now ready to use them.
For now we ignore this feature for config access with "alternates". On the long
run, we expect alternates to be handled as "aliases" by the config item
themself.
The goal of this class is allow explicit declaration for the available config
option. This class will hold the data for one specific config item.
To keep it simple we start centralizing the handling of the default config value.
In the future we can expect more data to be carried on this class. For example:
- documentation,
- status (experimental, advanced, normal, deprecated),
- aliases,
- expected type,
- etc...
The "#testcases" feature introduced by 250afd791085 has issues with "-i"
because "-i" uses "test.name.endswith('.t')" to test if a test is .t or not.
test.name could now be something like "test-foo.t (caseA)" so the above
endswith test is no longer valid.
This patch changes the test to use "self.path" which won't have the issue.
The .t file is both test input and reference output. They should always
match. However we have different code paths to read reference output
(Test.__init__ -> Test.readrefout) and test input (TTest._run) so they might
be inconsistent if somethings change the file between those two functions.
This patch assigns "lines" read by "_run" back to "_refout" if "_refout" is
not None (with --debug, see Test.readrefout) so reference output and test
input will always match.
The race condition is like:
1. run-tests.py reads test-a.t as reference output, content A
2. run-tests.py runs the test (which could be content B, another race
condition fixed by the next patch, but assume it's content A here)
3. something changes test-a.t to content C
4. run-tests.py compares test output (content D) with content A
5. with "-i", run-tests.py prompts diff(A, D), while the file has content
C instead of A at this time
This patch detects the above case and tell the user to rerun the test if
they want to apply test changes.
The old reversehunks code accesses "crecord.uihunk._hunk", which is the raw
recordhunk without crecord selection information, therefore "revert -i"
cannot revert individual lines, aka. issue5337.
The patch rewrites related logic to return the right reverse hunk for
revert. Namely,
1. "fromline" and "toline" are correctly swapped [1]
2. crecord.uihunk generates a correct reverse hunk [2]
Besides, reversehunks(hunks) will no longer modify its input "hunks", which
is more expected.
[1]: To explain why "fromline" and "toline" need to be swapped, take the
following example:
$ cat > a <<EOF
> 1
> 2
> 3
> 4
> EOF
$ cat > b <<EOF
> 2
> 3
> 5
> EOF
$ diff a b
1d0 <---- "1" is "fromline" and "0" is "toline"
< 1 and they are swapped if diff from the reversed direction
4c3 |
< 4 |
--- |
> 5 |
|
$ diff b a |
0a1 <---------+
> 1
3c4 <---- also "4c3" gets swapped to "3c4"
< 5
---
> 4
[2]: This is a bit tricky.
For example, given a file which is empty in working parent but has 3 lines
in working copy, and the user selection:
select hunk to discard
[x] +1
[ ] +2
[x] +3
The user intent is to drop "1" and "3" in working copy but keep "2", so the
reverse patch would be something like:
-1
2 (2 is a "context line")
-3
We cannot just take all selected lines and swap "-" and "+", which will be:
-1
-3
That patch won't apply because of "2". So the correct way is to insert "2"
as a "context line" by inserting it first then deleting it:
-2
+2
Therefore, the correct revert patch is:
-1
-2
+2
-3
It could be reordered to look more like a common diff hunk:
-1
-2
-3
+2
Note: It's possible to return multiple hunks so there won't be lines like
"-2", "+2". But the current implementation is much simpler.
For deletions, like the working parent has "1\n2\n3\n" and it was changed to
empty in working copy:
select hunk to discard
[x] -1
[ ] -2
[x] -3
The user intent is to drop the deletion of 1 and 3 (in other words, keep
those lines), but still delete "2".
The reverse patch is meant to be applied to working copy which is empty.
So the patch would be:
+1
+3
That is to say, there is no need to special handle the unselected "2" like
the above insertion case.
Changeset 3d003a7a1a87 change 'configwith' behavior so that the default value is
run through the conversion function. In parallel a new user of 'configwith' got
introduced unaware of this coming behavior change. This broke profiling.
We resolve the situation by having the new conversion function cope with a
default value already using the right type.
IIUC, letting the StopIteration through would not cause any bugs, but
not doing it makes the test-py3-commands.t pass.
I have also diligently gone through all uses of next() in our code
base. They either:
* are not called from a generator
* pass a default value to next()
* catch StopException
* work on infinite iterators
* request a fixed number of items that matches the generated number
* are about batching in wireproto which I didn't quite follow
I'd appreciate if Augie or someone else could take a look at the
wireproto batching and convince themselves that the next(batchable)
calls there will not raise a StopIteration.
I tried adding quotes to the $PYTHON variable, and also tried converting the
path from the current 'c:/Python/python.exe' form to '/c/python/python.exe', but
neither worked. I'm not sure why one of these needs '\"' around the variable
and the other doesn't.
These are the cases where either args is again passed as keyword argument or 1
or 2 elements are accessed. So it's better to add an r'' to prevent it
converting to bytes rather than doing the conversion of args.
This patch converts the args argument keys' to bytes wherever necessary as there
are some places where either args is not used or using r'' is better or args is
again passed as keyword arguments.
We were using str because on Python 2, str were bytes but now we have to use
bytes. Otherwise the if conditions fails and we have weird results from commands
on Python 3.
Previously, there is a 100 changes limit per name (bookmark or named
branch). And the user will get "too many shelved changes named %s" when they
are trying to shelve the 101th change. I hit that error message today.
This limit was introduced by the shelve extension since the beginning.
The function generating the names was called "gennames", under
"getshelvename".
There is another "gennames" under "backupfilename":
def backupfilename(self):
def gennames(base):
yield base
base, ext = base.rsplit('.', 1)
for i in itertools.count(1):
yield '%s-%d.%s' % (base, i, ext)
"itertools.count" is an endless counter.
Since the other "gennames" generates unlimited number of names, and the
changeset introducing the limit (49d4919d21) does not say why the limit
is useful. It seems safe to just remove the limit.
The format "%02d" was kept intentionally so existing shelved changes won't
break.
This should let 'configdate' delegate all special processing of the default
config value to the main 'config' method.
The default value for date (None) is still enforced in this method if no other
default were passed.
This should let 'configlist' delegate all special processing of the default
config value to the main 'config' method.
The default config value ([]) is still handled in this method.
This should let 'configwith' delegate all special processing of the default
config value to the main 'config' method.
This changeset introduce a small change in behavior since the default value is
run through the 'convert' function. This does not seems harmful and no actual
test break. This small change make the code simpler so I'm keeping it.
This should let 'configbool' delegate all special processing of the default
config value to the main 'config' method.
The default value for bool (False) is still enforced in this method if no other
default were passed.
We introduce a small object used to detect that no specific default value has
been passed to 'ui.config'. We need this explicit special value since "None" is
a valid and common default value.
The end goal here is to make progress on a centralised and explicit declaration
of the available config option. A first good usecase for this are "default"
value. Before starting looking further down this alley we needs to rework the
handling of default value in the 'ui' object to have all configxyz methods going
through the same logic. This is the first changeset on this trek.
By calling applybundle() with 'clonebundles' and the url instead of
calling processbundle(), the hooks will get different arguments:
HG_SOURCE will be 'clonebundles' instead of 'bundle2' and HG_URL will
be the url instead of 'bundle2'. This is consistent with the bundle1
behavior and seems like a bug fix, but I'm marking it BC anyway.
Again, commands.bookmark is getting too large. checkconflict already has
a lot of state and putting it in the bmstore makes more sense than
having it as a closure. This also allows extensions a place to override
this behavior.
While we're here, add a documentation string because, well, we should be
documenting more of our methods.
commands.bookmark has grown quite large with two closures already. Let's
split this up (and in the process allow extensions to override the
default behavior).
pip will check to see if it's the latest version, and complain if it isn't.
The --no-index flag implies the --disable-pip-version-check flag, and makes
the warning (and any associated network activity) go away.
This can happen if another process (even another hg process!) comes along and
removes the file at that time.
This partly resolves issue5584, but not completely -- a bogus dirstate update
can still happen. However, the full fix is too involved for stable.
For builds that run on hermetic environments, it's possible that the "less"
package is not installed by default, yet it's needed for tests to pass after
revision ca1519568a93 (which sets less as the fallback pager).
The contrib/zsh_completion file itself says to name it _hg.
With a name like `hg`, if the user has a line like `autoload ${^fpath}/*(N-.:t)`
in their zshrc, it will create a shell function named `hg` that will hide the
actual hg command and make hg unusable.
Separately from that though, the underscore prefix makes it actually work. The
zsh man page states:
The convention for autoloaded functions used in completion is that they
start with an underscore
This does not seem to just be a "convention", though. With the ill-advised line
removed from my zshrc and the file named
`/usr/local/share/zsh/site-functions/hg` (without the underscore), these
completions did not seem to get loaded and the ones from the zsh installation
were loaded instead. If I renamed them to be
`/usr/local/share/zsh/site-functions/_hg`, however, they were loaded.
I manually tested the above statement by starting a new zsh instance with the
file in `/usr/local/share/zsh/site-functions` with the following names:
- As `hg`, `which _hg_labels` did not show anything
- As `_hg`, `which _hg_labels` showed the expected function.
To quote `man 1 pkgbuild`:
--filter filter-expression
By default, --root will include the entire contents of the
given root-path in the package payload, except for any .svn
or CVS directories, and any .DS_Store files. You can override
these default filters by specifying one or more --filter
options. Each filter-expression is an re_format(7)
``extended'' expression: any path in the root which matches
any of the given expressions will be excluded from the pack-
age payload. (Note that specifying even one --filter inhibits
the default filters, so you must respecify the default fil-
ters if you still want them to be used.)
It turns out the default filter these days *also* includes .git and
.hg. Notice how that filter expression is a regular expression? That
(presumably unintentionally) prevents a file named "chg" or "_hg" from
getting included in the distribution. Many many thanks to spectral@
for trying to include a _hg file which led us to figure this bug out.
Bug filed with Apple for this as rdar://problem/32437369, mentioning
both the gap in documentation and the wrong defaults.
