Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create "watch" verb to start maintenance on a vanilla Git repo #254

Closed
derrickstolee opened this issue Nov 27, 2019 · 2 comments · Fixed by #275
Closed

Create "watch" verb to start maintenance on a vanilla Git repo #254

derrickstolee opened this issue Nov 27, 2019 · 2 comments · Fixed by #275
Assignees
Labels

Comments

@derrickstolee
Copy link
Contributor

Create a scalar watch verb to start watching a vanilla Git repo. This should result in:

  1. The repo is registered with the Scalar service.
  2. Background commit-graph and multi-pack-index steps work on that repo, but on the local .git folder (implicitly) instead of a shared cache.
  3. Background fetch can be done using git fetch but with a custom refspec to avoid updating the remote refs. (This may require a change to Git to avoid updating refs.)
  4. A few known-good config options are set in the local repo. We will want to make a split of our config options to be those for a "GVFS protocol" repo and a vanilla repo. (These should be updated through maintenance as part of Create a config maintenance step #252.)

This will lead naturally into allowing scalar clone to fallback to a vanilla Git repo when appropriate.

@derrickstolee derrickstolee self-assigned this Nov 27, 2019
@wilbaker
Copy link
Member

wilbaker commented Dec 4, 2019

This work might overlap/replace some of #214

@github-actions
Copy link

github-actions bot commented Jan 3, 2020

Labeling this issue as stale. There has been no activity for 30 days. Remove stale label or comment or this issue will be closed in 7 days.

@github-actions github-actions bot added the no-activity Stale issue or PR that will be automatically closed soon. label Jan 3, 2020
@derrickstolee derrickstolee removed the no-activity Stale issue or PR that will be automatically closed soon. label Jan 3, 2020
derrickstolee added a commit that referenced this issue Jan 8, 2020
Replaces #258. Resolves #254.

If you have a "vanilla" Git repo, then run `scalar repos add` in that repo. Scalar will detect the repo root, register that root with the service, and the maintenance steps will run.

The way we identify a vanilla Git repo (now) is if the object cache dir is not given by config and hence we do all operations on the local `.git` folder. This will not work with Git worktrees, but we will also not discover a `.git` _folder_ (worktrees use a `.git` _file_) so the enlistment will be invalid.

* The `commit-graph` task will generate the incremental commit-graph files using the `--reachable` option. This will be a no-op if the user has not changed their refs.

* The `packfile` task will write a `multi-pack-index` and do the expire/repack logic. To actually do something, the batch-size is decreased if the total pack size is smaller than 2gb. (This was done in #272.)

* The `loose-objects` task will delete loose objects already in pack-files and put them into a new `from-loose` pack. This required no change.

* The `fetch-commits-and-trees` task is renamed the `fetch` task. On a vanilla Git repo, it will simply call `git fetch <remote> --no-update-remote-refs +refs/head/*:refs/hidden/<remote>/*` for each `<remote>` given by `git remote`. This downloads a pack-file with the new objects not reachable form the current refs, but also does not update `refs/remotes/`. The user will see their refs update as normal, but the pack download is much smaller.

* The `config` task (added by #272) runs the necessary Git config.  This step is run in `scalar repos add`, but also in the background with the service. All config options become optional for vanilla Git repos, so a user can opt-out of the settings we recommend.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants