worktree checkout for clone and gix integration
#555
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
It works similarly to `PrepareFetch` and allows future upgrades and improvements thanks to being a builder essentially, while yielding a lot of control to the caller who decides everything about retries and whether or not to retain anything on disk even if the operation wasn't successful (with the default of removing leftovers).
This differentiation can one day allow to also checkout linked worktrees from a bare repository, which otherwise couldn't have a worktree post clone.
…pport for `init.defaultBranch`. (#450)
…information right after listing refs. (#450)
…self`. (#450) This generally makes returned values longer, and as long as one would expect.
It's only available after connecting to the server. Fetch, however, should check for it as well and abort, whereas here we dont't want to abort.
Entirely unsupported formats will error when fetching refs, and when cloning we get a chance to configure the repo before proceeding.
…xes. (#450) The current implementation might cause refspecs to end up ignored as they don't have a prefix, and in protocol V2 it would then fail to add a ref-spec filter which causes them to be missed. With `expand_prefix()`, we assure that there are all possible prefixes that can contain partial names, similar to what git does.
Previously specs could get filtered out server-side as a matching prefix was entirely missing.
… and `expanded_prefix()`. (#450) Previously, the expanded prefix would be a list of possibilities, even though it's such a common case that we really want to avoid spamming the remote about it when asking for HEAD during clone for instance.
This applies to bare and non-bare fetches equally, and provides the foundation for actually checking out something as we can just rely on what's in HEAD.
When configuring for packed-refs updates, previously one needed to provide a function to find objects that could not borrow data due to implicit 'static requirement. This has been lifted to allow it to access references to data on the stack.
…e::Name`. (#450) That way it's made clear the remote can also be a URL, while rejecting illformed UTF8. The latter isn't valid for remote names anyway as these only support a very limited character set. Note that this error currently is degenerated, making it appear if the remote name doesn't exists if illformed UTF-8 is found in what appears to be a symbolic ref.
`reference::remote::Name` (#450)
…#450) We can also parse it, adding yet another variant to `fetch::Refs`.
workaround for https://bugs.launchpad.net/ubuntu/+source/git/+bug/1993586 where git refuses to run submodule updates as they can be used as attack vector.
That way the caller has to be aware of the possibility of an unborn branch (probably the only unborn branch) on the remote.
…stination) (#450) That's exactly what git does, so it's probably the right thing to do if in doubt.
Previously we assumed this could only happen for `HEAD`, but in fact dangling symrefs are possible and they might end up in the server response that way.
Don't use `static` unless it's really needed
However, it's not yet refreshed in the repository we create, so that needs fixing. Implementing `repo.config()` would be too much effort for now, so let's continue forcing it in another way.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Even though early, add support for the existing worktree checkout functionality to the
git-repository::cloneimplementation, and make it available withgix cloneTasks
fetch_and_checkout()forgit_repository::clone::Prepareto support main worktree checkouts at firstobject-formatserver optioncheckout.workers, but prefer parallelism (deviation)refs/remotes/origin/HEAD, pointing to the remote tracking branchgix cloneas sibling togix fetchgix cloneSee how fast one can clone the complete linux kernel (using a RAM drive) with
gitoxidein comparison togitNext
Out of scope
checkout.defaultRemote,checkout.guess,submodule.recurse)Prior work
cloneforgit-repository#551