This repository has been archived by the owner on Nov 1, 2022. It is now read-only.
Move repo syncing into repo #940
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
squaremo
force-pushed
the
feature/repo-sync
branch
3 times, most recently
from
b7eb805 to
55f6ae8
Compare
squaremo
requested review from
errordeveloper and
stefanprodan
and removed request for
errordeveloper and
stefanprodan
|
Ops, accidental review requests. My apologues. |
This rewrites the git package so that there are two distinct abstractions: a self-syncing `Repo` and a working directory `Checkout`. `Repo` maintains a git mirror of an upstream git repository. It does both the initial clone and regular fetches, notifying on a channel when it's done so. The advantage of it being a mirror is that it will keep track of all refs (including notes), so does not need to be told to fetch particular branches. Since the daemon often needs to push new commits, then wait for them to be mirrored, there is also a synchronous method to fetch from upstream. Since it's just a mirror (i.e., has no working files), if the daemon needs to look at files it must clone the repo. There's now a helper method for this -- `*Daemon.WithClone` -- which makes sure things are tidied up afterward.
squaremo
force-pushed
the
feature/repo-sync
branch
from
4fe58cf to
c3ddea5
Compare
In particular, figure out the old and new revisions up front, rather than relying on HEAD and the tag to be in the right places, which is safe now but may not survive code changes as well.
squaremo
changed the title
Being able to refer to the Config fields by two paths is unnecessary, as is the mutex (which made some sense when the daemon was pulling refs occasionally, but no longer).
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
To ease the transition into supporting zero git repos, and later supporting more than one repo, this PR moves the periodic
git fetchloop into the git package.The effect is to make a git repo a state machine; it starts uncloned, then is mirrored, and finally tested to see if it's writable. Treating it as a state machine has a couple of benefits:
This PR doesn't change how the daemon works, in the main -- it will still wait for the repo to be ready before proceeding. To support zero git repos, we can remove that gate and respond to each API method by checking whether there's a git repo ready or not, and acting accordingly.
Tasting notes:
*Repo.Refresh(...)for when the daemon needs to wait for the repo to be up to date before proceeding.Repois a mirror, which means it doesn't have a working directory to look around in; the downside is you have to clone it every time you want to look at the files (a cache could be done in the daemon loop, if necessary). The upside (aside from some convenience in the git operations) is that there's no confusion over which things you can write to -- if you want to make a commit, you have to clone first.