Summary:
We take help info from the docstring but that'd disallow multiple registrations for a single function that can handle multiple subcommands. Refactor to let the decorator set an override.
So before you'd do this:
```
subcmd('foo')
def _foocmd(...):
"Help for foo command"
# implementation for foo
subcmd('bar')
def _barcmd(...):
"Help for bar command"
# implementation for bar
```
but you could not *combine* the implementations into one function and decorate both, because there is only the single docstring.
Now you can do:
```
subcmd('foo', help="Help for foo command")
subcmd('bar', help="Help for bar command")
def _fooandbarcmd(cmd, ...):
"This docstring is no longer used"
# implementation for foo and bar, combined, switching on the value of cmd
```
Reviewed By: ryanmce
Differential Revision: D7365390
fbshipit-source-id: 3d41542f1f197137ef13458e8d850cda8f53da74
Summary:
I want to add to helpcmd but with nested functions that's a lot more
complicated then it needs to be.
Reviewed By: ryanmce
Differential Revision: D7365391
fbshipit-source-id: 02092dd55f8f9521324b8ed51fa3134817454d36
Summary:
obsshelve: highlight shelved changes in smartlog (you can see with --hidden)
we highlighted only active shelved changes, those that has been unshelved are just ordinary hidden changes.
Reviewed By: ryanmce
Differential Revision: D7383800
fbshipit-source-id: 2df4092514d58315a6a204411feed99819df5c93
Summary:
add revsetpredicate to select shelved commits
if we are going to backup shelved commits, we should be able to select them
Reviewed By: ryanmce
Differential Revision: D7381561
fbshipit-source-id: 35aa0ad9a77fa9df94e91b571279eaa4301c85f3
Summary:
Raise this instead of RepoError. This way commands can catch and auto-recover the
repo, if appropriate. Right now I only do this inside megarepo commands.
Reviewed By: DurhamG
Differential Revision: D7363245
fbshipit-source-id: 0a6cab92a4ff6e50cd269bdddadee47be6199ebd
Summary: Use 256 colors if supported, or fallback to 16 colors.
Reviewed By: singhsrb
Differential Revision: D7388275
fbshipit-source-id: e7be447f2b900e384e9280f92ea8f881747493e4
Summary:
Allow color config to be something like `color132:red` that is to use 256
color if supported, but fallback to `red`.
To get a consistent test output. `run-tests.py` is changed to disable 256
color support explicitly.
Reviewed By: singhsrb
Differential Revision: D7388277
fbshipit-source-id: da74ae8fc70c971901d56a6985976db44cbec0d9
Summary:
This would allow us to use 256 colors, which seems to be widely available
on modern terminals (including mosh and tmux).
Reviewed By: singhsrb
Differential Revision: D7388279
fbshipit-source-id: 726a364ed5d3acc449f0d7ada14c42e4b68424ec
Summary:
This allows us to treat terminals with 256 color support differently.
The motivation is, the bright colors seem to work fine on Linux. But they
appear to have minor differences on OSX terminals (iTerm2 or Terminal.app).
Using explicit 256 colors is better.
Reviewed By: singhsrb
Differential Revision: D7388276
fbshipit-source-id: 970ee18f0f5bb9cc4bb5c39b2b46b354525b3d55
Summary:
As suggested by wez, "dim" is less supported than the bright colors.
So let's use the bright versions instead. Basically, replacing "red",
"red dim" with "brightred" and "red".
Reviewed By: singhsrb
Differential Revision: D7387254
fbshipit-source-id: f741d9e1c12115acdd1a3a2cae1658d8fae534bf
Summary:
Most terminals support 16 colors these days. This is manually tested
with: tmux (2.2), mosh (1.3.0), screen (4.04) from Linux (xfce) and
OS X Terminal.app and iTerm 2.
Note: aside from "screen" with default configuration, the terminals
also have 256 colors support. "screen" can support 256 colors if it's
started with TERM=xterm-256color.
See https://en.wikipedia.org/wiki/ANSI_escape_code for details.
Reviewed By: singhsrb
Differential Revision: D7387258
fbshipit-source-id: e7b2437fee2b4e593077bb3f44143c86ece93a8f
Summary:
The reason why we would like to have a real user there is that
we may want to start push shelved changes in commit cloud, so
we should have correct user on the commit
Reviewed By: ryanmce
Differential Revision: D7380732
fbshipit-source-id: 27b07f992a3e394016ce69e1dc9694a4dd1c336b
Summary: obsshelve: do not use secret phase
Reviewed By: ryanmce
Differential Revision: D7380531
fbshipit-source-id: 21538d42a43f019b894dd1a77ba0adc67798936a
Summary:
The progress bar runs in another thread and may draw " <=> " which pollutes the
current screen.
Make `ui.system` suspend the progress bar automatically. This should work for
the "invoking editor" case. I think sshaskpass and curses might also need to
suspend the progress bar but those are trickier.
Reviewed By: singhsrb
Differential Revision: D7377492
fbshipit-source-id: 833ac724bbe4f9c630ca37567dc088f7279dd67e
Summary:
The flush method will write buffered data to disk.
A mistake in Root entry serialization is fixed - it needs to translate dirty
offsets to non-dirty ones.
Reviewed By: DurhamG
Differential Revision: D7223729
fbshipit-source-id: baeaab27627d6cfb7c5798d3a39be4d2b8811e5f
Summary:
Add the main `Index` structure and its constructor.
The structure focus on the index logic itself. It does not have the checksum
part yet.
Some notes about choices made:
- The use of mmap: mmap is good for random I/O, and has the benefit of
sharing buffers between processes reading the same file. We may be able to
do good user-space caching for the random I/O part. But it's harder to
share the buffers between processes.
- The "read_only" auto decision. Common "open" pattern requires the caller
to pass whether they want to read or write. The index makes the decision
for the caller for convenience (ex. running "hg log" on somebody else's
repo).
- The "load root entry from the end of the file" feature. It's just for
convenience for users wanting to use the Index in a standalone way. We
probably
Reviewed By: DurhamG
Differential Revision: D7208358
fbshipit-source-id: 14b74d7e32ef28bd5bc3483fd560c489d36bf8e5
Summary:
This is based on the hg show implementation. hg sparse --list-profiles is not yet widely known, so now is the time to move it to a subcommand.
This is the first step in untangling the mess that is the `hg sparse` forest of options.
Currently, all switches on the command are mutually exclusive, except for `—force` and `—template`, which each only apply to a subset of the actions the other switches affect.
Subcommands are the right pattern for mutually-exclusive actions that can accept their own individual switches.
Reviewed By: quark-zju
Differential Revision: D7350928
fbshipit-source-id: d03014cf7edd2f089f670d11465c70940d96c070
Summary:
A simple utility that does paths <-> local bytes conversion. It's needed
since Mercurial stores paths using local encoding in manifests.
For POSIX, the code is zero-cost - no real conversion or error can happen.
This is in theory cheaper than what treedirstate does.
For Windows, the "local_encoding" crate is selected as Yuya suggested the
`MultiByteToWideChar` Win32 API [1] and "local_encoding" uses it. It does
the right thing given my experiment with GBK (Chinese, simplified) encoding.
```
....
C:\Users\quark\enc>hg debugshell --config extensions.debugshell=
>>> repo[0].manifest().text()
'\xc4\xbf\xc2\xbc1/\xce\xc4\xbc\xfe1\x00b80de5d138758541c5f05265ad144ab9fa86d1db\n'
>>> repo[0].files()
['\xc4\xbf\xc2\xbc1/\xce\xc4\xbc\xfe1']
extern crate local_encoding;
use std::path::PathBuf;
use local_encoding::{Encoder, Encoding};
const mpath: &[u8] = b"\xc4\xbf\xc2\xbc1/\xce\xc4\xbc\xfe1";
fn main() {
let p = PathBuf::from(Encoding::OEM.to_string(mpath).unwrap());
println!("exists: {}", p.exists());
println!("mpath len: {}, osstr len: {}", mpath.len(), p.as_path().as_os_str().len());
}
exists: true
mpath len: 11, osstr len: 15
```
In the future, we might normalize the paths to UTF-8 before storing them in
manifest to avoid issues.
Differential Revision: D7319604
fbshipit-source-id: a7ed5284be116c4176598b4c742e8228abcc3b02
Summary:
We've seen cases when `suprocess.Popen` fails [1], [2]. It might happen if
`arc` binary is not in `$PATH` env var. Let's fail gracefully.
[1] https://fburl.com/7hcq73as
[2] https://fburl.com/u1v0es8q
Differential Revision: D7365459
fbshipit-source-id: ce838f434cb81211c334d6f170fd25ef30edaabd
Summary:
Previously we were storing the changelog on the manifestlog and using
it to resolve linkrevs before serializing them. It turns out the changelog can
be invalidated at a different rate than the manifestlog, so we could encounter
issues where the manifestlog held a reference to the old changelog.
To fix this, let's hold a reference to the repo and access the changelog from
there when we need it. This introduces a circular reference between the
manifestlog and the repo, but it's probably fine for now until we can get rid of
the need for changelog invalidation.
Reviewed By: singhsrb
Differential Revision: D7360321
fbshipit-source-id: 2317c7fcd6b307a50b64f0c5df97dda2955f3e21
Summary:
When remotefilelog downloads filelog information for a particular file, set the
progress bar item to that file. This means if we get stuck on a particular
file, there is feedback to the user as to which file that is.
Reviewed By: quark-zju
Differential Revision: D7329503
fbshipit-source-id: 94416962cdc4c97994f76e8ed9203823aeca3d64
Summary:
Remove ui.progress as a method of updating progress. All progress bars now go
through new-style progress bars.
This also splits out the rendering of progress bars from the reporting of
progress. All tests are updated to use new-style debug progress bars, which
simply report the position of the progress bar. Rendering of progress bars
will be tested separately once the progress bar engine has been rewritten.
Reviewed By: quark-zju
Differential Revision: D7329488
fbshipit-source-id: 14f8ab67365ddd98b74986aa25d9abc7a0546144
Summary:
httpconnection uses old-style progress bars in a way that isn't easy to
replicate using new-style progress bars. Remove it for now, it can be added
back in later in the right place.
Reviewed By: quark-zju
Differential Revision: D7329486
fbshipit-source-id: 814c55d7a5bb5c97fc6b3967510ed656110038c8
