We've been seeing "Task X took Y seconds" warnings in our tests for a
long time, especially on Windows. Running git commands synchronously
blocks other tasks from running, like display redrawing. It's bad
practice in an async program.
One of the barriers to async-ifying the cache code earlier was that many
commands relied on having exclusive ownership of the index file while
they were running. For example, 1) read a tree into the index, 2) merge
another tree into some subdirectory, 3) write out the result. If any
other git commands ran in the middle of that, it would screw up the
result. So we need to rewrite every cache function to use its own
temporary index file, if we want them to run in parallel.
The reason I'm finally getting around to this now, is that I'm trying to
reduce the number of git commands that run in a no-op sync. One of the
optimizations I'm going to want to do, is to reuse the index file from
the last sync, so that we don't need a `read-tree` and an `update-index`
just to set us up for `diff-files`. But the plumbing to do that right is
pretty much the same as what we should be doing to run every git command
with its own index anyway. So let's just bite the bullet and do that
now, and then reusing index files will be easy after that.
Summary:
This is similar to something like `--file=myname --sync-dir=.`, except
that it allows syncing from a subdirectory like you can with the default
settings.
Also in this diff, changing `--peru-file` to `--file`.
Closes https://github.com/buildinspace/peru/issues/108.
Test Plan: Integration test for `--file-basename`.
Reviewers: sean
Differential Revision: https://phabricator.buildinspace.com/D213
Summary:
We want to be able to run peru from subdirs below the root of a project. Peru
should walk up the directory hierarchy until it finds a peru.yaml file, and
interpret that as the root of the project. The core of this logic is the new
function `find_peru_file`.
Lots of code up until this point has been working under the assumption that
peru's current working directory is also the root of the project, and this
assumption is no longer true. That means several features (relative overrides,
relative module paths) don't work properly away from the root yet; followup
diffs will fix these and add tests for them.
We could do something drastic like have peru cd to the root after it's
detected, but I think this is going to cause more trouble than it saves.
Thoughts greatly appreciated on this.
Test Plan: New unit and integration tests.
Reviewers: sean
Differential Revision: https://phabricator.buildinspace.com/D17
