Summary:
Like it says in the title. Sometimes it's helpful to reuse mkscratch's
configuration to place scratch files in the right place, but the paths it
provides might be too long for some applications.
Reviewed By: quark-zju
Differential Revision: D43390592
fbshipit-source-id: b10246be1552c92c0a184f1d9f7ab3e64654163a
Summary:
Replaces the dashed and solid arrow emoji, used to represent start and finish
events respectively, with an arrow and checkmark.
With my terminal font, I never noticed there were actually two different arrow
types in the output...
Reviewed By: kmancini
Differential Revision: D42971357
fbshipit-source-id: 9e569a461d77b6df9993554b0edccd85fe77d9f2
Summary:
feat(scm): Add revset aliases for `next` and `prev`
In the same way you can `sl go top`, it seems logical to also have
`sl go next`. However, instead it is `sl next`. While I normally remember to
do `sl prev`, I sometimes accidentally do `sl go prev` out of habbit and get an
error. Instead, let's simply add two revset aliases for `next` and `prev` to
make sl more intuitive.
The revset functions were added by D43383303.
This change adds convenient aliases so one can use `next`, `prev` without typing `()`:
next
prev
previous
Number of steps can still be specified using the function form:
next(2)
prev(3)
previous(4)
Closes https://github.com/facebook/sapling/issues/444
Pull Request resolved: https://github.com/facebook/sapling/pull/448
Test Plan:
Automated tested blocked on https://github.com/facebook/sapling/issues/447
Manually tested by running `sl go next` and `sl go prev` and verifying I ended
up in the right spot.
Reviewed By: muirdm
Differential Revision: D43329058
Pulled By: quark-zju
fbshipit-source-id: 6fa5c6e6e41971f8f15b784586176b089c5f0027
Summary:
Expose stack movement logic as revset functions so they can be used like:
# when stack forks in the middle and you want to histedit across the fork
histedit 'bottom()'
# when moving another stack on top of the current stack
rebase -s X -d 'top()'
Reviewed By: muirdm
Differential Revision: D43383303
fbshipit-source-id: b1f68fe8bdb41988576fcb1ca0a17dcf235c5a55
Summary:
`types` conflicts with stdlib `types`. This prevents running doctests like:
hg debugruntest revsetlang.py
Given its content is just the `ui` type, let's migrate its users to fully
qualified type `edenscm.ui.ui` explicitly.
Before:
% lrt revsetlang.py
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/lib64/python3.8/multiprocessing/__init__.py", line 16, in <module>
from . import context
File "/usr/lib64/python3.8/multiprocessing/context.py", line 5, in <module>
from . import process
File "/usr/lib64/python3.8/multiprocessing/process.py", line 19, in <module>
import signal
File "/usr/lib64/python3.8/signal.py", line 4, in <module>
from enum import IntEnum as _IntEnum
File "/usr/lib64/python3.8/enum.py", line 2, in <module>
from types import MappingProxyType, DynamicClassAttribute
File "/data/users/quark/fbsource/fbcode/eden/scm/edenscm/types.py", line 16, in <module>
from .ui import ui
ImportError: attempted relative import with no known parent package
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/lib64/python3.8/multiprocessing/__init__.py", line 16, in <module>
from . import context
File "/usr/lib64/python3.8/multiprocessing/context.py", line 5, in <module>
from . import process
File "/usr/lib64/python3.8/multiprocessing/process.py", line 19, in <module>
import signal
File "/usr/lib64/python3.8/signal.py", line 4, in <module>
from enum import IntEnum as _IntEnum
File "/usr/lib64/python3.8/enum.py", line 2, in <module>
from types import MappingProxyType, DynamicClassAttribute
File "/data/users/quark/fbsource/fbcode/eden/scm/edenscm/types.py", line 16, in <module>
from .ui import ui
ImportError: attempted relative import with no known parent package
# Ran 0 tests, 0 skipped, 0 failed.
After:
% lrt revsetlang.py
# Ran 1 tests, 0 skipped, 0 failed.
Reviewed By: muirdm
Differential Revision: D43383304
fbshipit-source-id: 1b30303046cd42ab730734f147ab51530b1916b3
Summary:
Revset aliases can be functions or symbols. Treat them and functions with
different number of args differently so:
[revsetalias]
f = g1
f(a) = g2
f(a,b) = g3
Can be defined without conflict on the name `f`. Revset expressions like `f`,
`f(x)`, `f(x,y)` will choose the right alias to expand.
Also forbid expanding a function name to a function call, since that does not
make sense. Revset functions always return a set. They never return a string.
Note template functions might return a string, but it seems extremely rare
for that to be useful in the alias function name case.
This allows defining more "interesting" aliases like:
next = next()
which is used by an upcoming change.
Note extensions using `registrar.revsetpredicate` can only define revset
functions. Revset alias is the only way to make a symbol available without
requiring `()`.
Before this change, those aliases with the same name would simply clash,
and `f = f()` would infinite expand and error out.
Reviewed By: muirdm
Differential Revision: D43383302
fbshipit-source-id: 79796d4d67194e7221c2aa62f43bff5e9d55c953
Summary:
Add completion for sapling
Make completion work for `sl` by adding `sl=hg` to the compdef
Pull Request resolved: https://github.com/facebook/sapling/pull/369
Test Plan:
Manually
```sh
$ ln -sv ~+/eden/scm/contrib/zsh_completion /usr/local/share/zsh/site-functions
$ exec zsh # might have to clear compinit cache
$ sl g
gc githelp goto graft grep
```
(and this does not work on main at the time of writing)
Reviewed By: muirdm
Differential Revision: D43329103
Pulled By: quark-zju
fbshipit-source-id: a8220efa64acda0e988b92418321675a6e3dd7a5
Summary:
smartlog: add option to hide '~' marker for unlogged ancestors
I made a template for 'sl smartlog' which is compact compared to the default:
o a0f0b95622 my commit
o 10 hours ago remote/main
|
~
Unfortunately, the '|' and '~' lines take up a lot of space. Add an option to
disable these lines, making the output nice and tidy:
o a0f0b95622 my commit
o 10 hours ago remote/main
Pull Request resolved: https://github.com/facebook/sapling/pull/456
Test Plan:
$ cd tests
$ python run-tests.py test-log-graph-show-abbreviated-ancestors.t
Reviewed By: muirdm
Differential Revision: D43328964
Pulled By: quark-zju
fbshipit-source-id: f1cc1e081e50f780d6e7e7519c42f72ed5deaea1
Summary:
split commits_to_process into a function, future PRs (maybe in this stack) will utilize this function in other modules for implememting `sl pr land`. Even if `sl pr land` is not interesting, this still makes this functionality portable for future use cases
Pull Request resolved: https://github.com/facebook/sapling/pull/445
Reviewed By: muirdm
Differential Revision: D43328698
Pulled By: quark-zju
fbshipit-source-id: 9ea5607de3835620541d2306e9f5b45866678a58
Summary:
Instead of just showing `?` or `*`, show one of each symbol in the
dirty status. This means there will be a maximum of 5 characters at the end of
the prompt, which is fine.
Pull Request resolved: https://github.com/facebook/sapling/pull/349
Test Plan:
Seems to work:
```
fbsource>scm % setopt PROMPT_SUBST
fbsource>scm % source contrib/scm-prompt.sh
fbsource>scm % export SHOW_DIRTY_STATE=1
fbsource>scm % export PS1='$(_scm_prompt)$USER@%m:%~%% '
(158b00d6b? M)muirdm@muirdm-mbp:~/fbsource/fbcode/eden/scm%
Reviewed By: muirdm
Differential Revision: D43326525
Pulled By: quark-zju
fbshipit-source-id: 94c0a85e4cf4ffcc5c7c8db9ed64f6ea6d1564a2
Summary:
Let's decouple getting the latest id from waiting for it. This way we can wait
on arbitrary bookmark update log ids.
Reviewed By: yancouto
Differential Revision: D43363645
fbshipit-source-id: 8447ecd39e1eb1e957410fa1022b8c7a628a1eee
Summary:
slow_bookmark_mover's pushes often move bookmark by 100s of commits at the
time. We don't want to combine such pushes into a single bundle with others.
Reviewed By: yancouto
Differential Revision: D43356668
fbshipit-source-id: e9014f633c0d7c56b655c5b730d229b87736123f
Summary:
Currently the mononoke_hg_sync_job either prepares a bundle or sends it to hg
servers. Those steps could be done concurrently. This dfff creates a stream of
bundles that is buffered so the syncing to hg servers doesn't have to wait for
new bundle generation.
The implementation is a bit gross, unfortunately I couldn't get the lifetimes
arround `scan()` transofrmer to work without mutex and I hit higher-order
lifetime exception few times which caused me to wrap some things in Arc.
Reviewed By: yancouto
Differential Revision: D43306918
fbshipit-source-id: b2ec3da21f4791c57a02fcfe76c735f4fdb16efd
Summary:
git: respect 'default-push' path if present
In non-Git mode, 'hg push' (without an explicit path) pushes to the
'default-push' path if present, falling back to the 'default' path.
In Git mode, 'sl push' (without an explicit path) always pushes to the 'default'
path. 'default-push' is ignored.
Teach Git mode to push to 'default-push' if present, similar to how it works in
non-Git mode.
This commit only affects 'sl push'. 'sl pr submit' still ignores the
'default-push' path.
Pull Request resolved: https://github.com/facebook/sapling/pull/469
Test Plan: $ (cd tests && python run-tests.py test-git-push-default-push.t)
Reviewed By: muirdm
Differential Revision: D43336914
Pulled By: quark-zju
fbshipit-source-id: f11c45fb2bd8678b6be7294bf15359131db0ee2e
Summary:
Various minor changes to the sapling repo while hacking on Fedora packaging.
These changes works with https://gist.github.com/kiilerix/b32cb9688d2d6e9e752e91e2ca4c30e6 .
Still a long way to go to be able to package offline and reproducible.
Pull Request resolved: https://github.com/facebook/sapling/pull/451
Reviewed By: muirdm
Differential Revision: D43327153
Pulled By: quark-zju
fbshipit-source-id: 33326188e17e451c9268038ac783c1fda86db5f8
Summary: Certain error types have the same error handling logic. Merge them.
Reviewed By: muirdm
Differential Revision: D43335811
fbshipit-source-id: a3df1391a6d461f4713b5e92e8e005107337fddb
Summary:
The name RustError is kind of confusing:
- Some people confuse it and get bad impression on the Rust language.
- The name is not like Exception, or RuntimeError that are considered bad
practice, but it is "one type catching all" type that is a bad practice.
Rename it to `UncategorizedNativeError` so it's clear:
- It's an uncategorized error that is unlikely a good practice.
- It does not intend to hurt reputation of the Rust language.
- It is from the native code, Rust, C, or C++.
Reviewed By: muirdm
Differential Revision: D43335812
fbshipit-source-id: 30ae3fa18d6f06963a7556399bee7dcb647ab1d5
Summary:
Allow `sl init --git` in non-empty directory
Currently, running `sl init --git` for a nonempty directory gives the
follwing error:
```
destination <..> already exists
```
This seems like an arbitary restriction to me, so I removed it.
It looks like this restriction was put in place because `sl init` and
`sl clone` share similar logic. Is there any other reason for not allowing
`sl init` in non-empty directories?
Also, this commit fixes an imprecise error message when `init`ing a repository
in a non-directory (i.e. a file)
Pull Request resolved: https://github.com/facebook/sapling/pull/463
Test Plan:
Blocked by https://github.com/facebook/sapling/issues/447
manually tested with
(should pass, but didn't before)
```sh
DIR=/tmp/sl-clone-test zsh -c 'rm -rf $DIR; mkdir $DIR && cd $DIR && touch hi && CHGDISABLE=1 sl init --git .'
```
(should still fail)
```sh
DIR=/tmp/sl-clone-test REPO=git@github.com:97-things/97-things-every-programmer-should-know.git zsh -c 'rm -rf $DIR; mkdir $DIR && cd $DIR && CHGDISABLE=1 sl clone $REPO && CHGDISABLE=1 sl clone $REPO'
```
---
Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/sapling/pull/463).
* __->__ https://github.com/facebook/sapling/issues/463
Reviewed By: muirdm
Differential Revision: D43328481
Pulled By: quark-zju
fbshipit-source-id: 0a82d88c393c847579e644b7c368db09cab51003
Summary:
If a directory is non-empty and init fails, it should not crash the program
(going through uncaught RustError code path).
Reviewed By: muirdm
Differential Revision: D43335814
fbshipit-source-id: c6e60b97e396548a5b3cd23ab9ffc46c2a6d2528
Summary: `eden prefetch-profile activate` currently fails if the prefetch profile we're trying to activate is already active. I don't really consider this a failure, as the intended profile is already activated. Instead of returning an error, we should just return early.
Reviewed By: genevievehelsel
Differential Revision: D43377801
fbshipit-source-id: 59c34ada539dd0b0789ec48f3a2ed2d7e66558cb
Summary:
We've had Rust prefetch-profiles for a while now. It's pretty safe at this point to delete the Python version.
quiet_delete
Reviewed By: genevievehelsel
Differential Revision: D43375605
fbshipit-source-id: f3670434b9884e2c7dc2c1429cf90b07334611af
Summary:
This diff has two major changes:
- Test for the upload_git_object method to ensure that the method behaves as expected in all cases
- Extension of the vallidations in the method to reject requests for uploading raw file blobs
Differential Revision: D43276298
fbshipit-source-id: 821a906b2bb5830f2162c432fc74db75f9ea11b8
Summary:
Our fsck does not properly handle renamed placeholders: renamed files
do not need to be present in scm and they may not be full or hydrated.
For example: clone a new repo, move a file. That file will just be a
placeholder. But eden materializes all renamed files. So the inode will
be materialized, but the contents will not be present on disk.
This works out ok, because when ProjFS reads the file, it will send a
"read" request for the old path. And EdenFS serves read requests
directly out of the source control state.
Our Fsck assumes that all files must have their contents present on
disk or exist in source control. Which generally make sense since
file contents should be read from disk or source control. But renamed
files are an exception.
Generally, this materializing renamed files without them being at least
hydrated when we gernally have a rule in windows eden that this should
not be the case, does feel kinda hacky. But we need to materialize them
for status and diff I think. So the option is to force hydrate things as they
are renamed. And this would mean unnecessarily fetching contents.
So I am not sure that its worth it.
We can at least fix this fsck issues for now, by fsck-ing renamed files
like populated & materialized ones. The inode should be materialized,
and we need to ensure the inode is the correct type. This diff teaches
fsck to detect renamed files and fix them up like materialized ones.
I discovered another fsck bug while fixing this. When files are removed
while eden is stoped, Eden will keep them in the overlay, but does not
add them back to disk. So the file will be removed from disk, but present
in the overlay. hg status does not match disk in this case ...To fix in a later
diff.
Reviewed By: xavierd
Differential Revision: D42268664
fbshipit-source-id: cb36a6513bb30a1c1951b5c8cc0ca66f78edbb67
Summary:
Previously if the dirstate and working copy were out of sync with regard to the sparse profile, the Python "sl status" would report modified files even if they were excluded in the sparse profile. Fix by applying the sparse matcher in dirstate.status().
This fixes "sl status" to be consistent with "sl commit", "sl diff", etc. in that it filters out files not in the sparse profile.
Note that this does not fix the reverse case where a file was added to .hg/sparse without going through "hg". The file won't be tracked until "hg sparse include" or "hg sparse refresh" is called. Fixing this is more involved, but Jun suggests storing the sparse profile in the dirstate metadata so status can detect out-of-band sparse changes and automatically refresh the (minimal) differences.
Reviewed By: zzl0
Differential Revision: D43256615
fbshipit-source-id: fda28d4fb833ec36c2d57f3be626e325da3be654
Summary: The Python "status" command does not skip dirty dirstate entries that are excluded by the sparse profile. These files will not be included in a subsequent "sl commit", which is a good indication this behavior is incorrect.
Reviewed By: zzl0
Differential Revision: D43256616
fbshipit-source-id: f5ee102b15aac708255fc9278c88c414d7e4e0e8
Summary:
Hooks are annoying since it is hard to control which "sl" binary is used to invoke the hook. Instead, let's just call the landed pr hook inline using the classic extension wrapping technique.
I made a lazy decision to disable the hide-landed-commits logic by default for tests since the additional GH activity requires tests to mock more stuff out that they aren't necessarily testing.
I also moved the enablement of the "github" extension from the sapling config (which is activated when $0 is "sl") to the git config (which is activated when in a git repo). It doesn't seem like GH integration needs to be coupled with the Sapling rebrand.
Fixes#457
Reviewed By: quark-zju
Differential Revision: D43276199
fbshipit-source-id: 3feb7621a037190044c41020e6a965f8b62bc432
Summary: The "debugprmarker" command can be part of the github extension.
Reviewed By: quark-zju
Differential Revision: D43208768
fbshipit-source-id: efcba0728d9508c9a02cf1361c5e37b35757ac34
Summary:
This command was not working because it always needs a remapping of the commit, but on this case it was a `EquivalentWorkingCopyAncestor`.
This is probably out of data, as it uses a bunch of manual "CommitSyncer"s instead of using `Syncers` which have both directions and are easier to use.
Reviewed By: mitrandir77
Differential Revision: D43047554
fbshipit-source-id: 5f1050c0009355c735ceba93b3da9697661230b1
Summary: Now as the server side has a new poll api, let's use it on the client side. I also improved some scuba logging.
Reviewed By: markbt
Differential Revision: D43143926
fbshipit-source-id: 78756ed7747e7d29ef67f632826a8a63ccef1091
