The fix for this Git security issue [1] involved disabling the local
clone optimization when the repository contains symbolic links. The
security fix broke this particular test; this patch works around the
fix.
[1]: https://github.com/git/git/security/advisories/GHSA-3wp6-j8xr-qw85
Allows one to store files in a directory or git-repo without the leading
`.`, as in:
```
dotconf:
├── README.md
├── bin
│ ├── dotbot
│ ├── look
│ ├── pbfile
│ └── ...
├── dot
│ ├── bashrc
│ ├── gitconfig
│ ├── gitignore
│ ├── gorc
│ ├── login
│ ├── ...
│ ├── zshrc
│ └── zshenv
```
Can take a many-line dotbot.yml listing **each** file in `dotconf/dot`,
reducing it to five lines:
```
- link:
~/:
path: dotconf/dot/*
glob: true
prefix: '.'
```
FIXES: #259
For example, will handle an entire directory tree of files, linking all
files:
```
- link:
~/.config/:
path: dotconf/config/**
glob: true
```
NOTE, this feature requires newer versions of `glob()` (Python >= 3.5),
and `dotbot` will throw an error if using an earlier version of python.
For testing purposes, added:
- ability to skip tests in test harness
- added testing for older Python(s).
FIXES: #270
- Added `exclude` parameter to _link_. Now, an array of glob patterns
can be given that will be used to remove items from a glob match.
This parameter will only have an effect when `glob` is `true`.
- Updated README to add description for `exclude` and add in examples.
Resolves#247
In the setup guide in the README, we have people start out with an empty
file (created using `touch`). Before this patch, Dotbot gave the
following error:
Configuration file must be a list of tasks
Instead, with this patch, Dotbot says:
Configuration file is empty, no work to do
This change was prompted by
https://github.com/anishathalye/dotbot/pull/226.
This patch makes the tests (including the test driver) run entirely
inside Vagrant, which avoids calling the very slow `vagrant` driver many
times for running the tests. On my machine, `./test` runs in 22 seconds,
down from hundreds of seconds prior to this patch.
This also has the nice side effect of matching how the Travis CI tests
were run, so there's no need for a separate `test_travis` anymore.
Previously, clean read the defaults once, and then it updated the
setting for each entry it read. This resulted in the defaults being
clobbered and then not being respected for subsequent entries. This
patch fixes the issue by re-reading the defaults before processing each
item.
The other plugins (link, shell) do not have this problem.
Previously, PyYAML was hosted on BitBucket, so we had a mirror of the
repo on GitHub. Now, official hosting has moved to GitHub, so we can
point to the official repository instead. Thanks to Marco A. Feliu
<marco.feliu@nianet.org> for pointing this out.
This patch also updates the install shim to update submodule URLs. To
preserve the functionality of earlier Dotbot versions, we will need to
maintain 'https://github.com/anishathalye/pyyaml'. Because old versions
of the install shim used with new Dotbot versions will not update
submodule URLs, we will need to keep the old repository in sync with the
upstream repository as we upgrade PyYAML versions.
This patch also upgrades the dependency to PyYAML 3.12.
Prior to this patch, Dotbot was relying on running with the base
directory being the current working directory. In practice, it was
relying on the install shim to set up this context. It makes more sense
sense to actually execute `chdir()` within Dotbot itself, rather than
relying on the install shim to do so.
Because 'bin/dotbot' is a hybrid sh/Python script that finds the
appropriate Python binary and then runs, the test code should not invoke
it as an sh script when sh does not source the pyenv initialization
script.
The fix implemented in this patch is to directly run 'bin/dotbot' as a
Python script using 'python', which when called from bash, will run with
the correct Python version (because bash is set up to source the pyenv
initialization script).
Previous to this patch, having a config like the following would not
work properly:
- link:
~/a: ~/b
This was because the '~' was expanded on the left hand side (the link
target), but not the right hand side (the link source). It was necessary
to use a workaround like this:
- link:
~/a: $HOME/b
This was because variable expansion was being done, but user expansion
was not being done.
This commit adds support for using '~' in the link source.
