Skip to content

Shallow Clone Support #6393

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

Closed
wants to merge 60 commits into from
Closed

Shallow Clone Support #6393

wants to merge 60 commits into from

Conversation

lya001
Copy link
Contributor

@lya001 lya001 commented Aug 30, 2022

This PR combines #4747 and #5254 to support:

  1. Performing git operations on local shallow repositories
  2. Git cloning with a depth to obtain a shallow repository
  3. Performing git fetch unshallow on shallow repositories, to convert them into full clones

If preferred, can be separated into support for local shallow clones and network.

This will be used in MATLAB to support users working with shallow clones, and a feature flag is added for the features.

Tests were added for all three features and so far, the features are functional.

To clone a shallow repository, set clone_opts.fetch_opts.depth to be a positive integer depth.

To fetch unshallow a shallow repository, set fetch_opts.unshallow = 1;

Any feedback is greatly appreciated!

tiennou and others added 30 commits June 27, 2020 14:33
This represents (old-style) grafted commits, a.k.a an array of
overridden parents for a commit's OID.
This wires git_repository to open the .git/info/grafts file and load its
contents as git_commit_grafts objects.
In order to increase maintainability in the future, we should try to
make structures as self-contained and opaque to its users as possible.
Thus it is probably not a good idea to just typedef `git_graftmap` to
`git_oidmap`, as that will make it a lot harder in the future to extend
the API in the future, if this need ever arises.

Refactor the code to instead declare a real structure `git_grafts`,
which is completely opaque to its callers.
Instead of using the newly introduced `git_buf_foreach_line`, which
modifies the buffer itself, we should try to use our existing parsing
infrastructure in "parse.h".

Convert the grafts parsing code to make use of `git_parse_ctx`. Remove
the `git_buf_foreach_line` macro, as grafts have been its sole user.
Parsing of grafts files is currently contained in the repository code.
To make grafts-related logic more self-contained, move it into
"grafts.c" instead.
The shallow roots are in fact another user of the grafting mechanism,
and in essence they do use the same file format for grafted commits.
Thus, instead of hand-coding the parsing logic a second time, we can
just reuse the `git_grafts` structure for shallow commits, as well.
When loading shallow grafts, we add each of the grafting commits to the
grafts backed by ".git/info/grafts". Keeping track of both grafts
separately, but partially storing them in a common grafts structure is
likely to lead to inconsistencies. In fact, there already are
inconsistencies if refreshing shallow grafts at a later point, as we
only refresh the shallows, but not the normal grafts in that case.

Disentangle both grafting stores and instead check both separately when
parsing commits.
The refresh logic for both "normal" and shallow grafts are currently
part of the repository code and implemented twice. Unify them into the
grafts code by introducing two new functions to create grafts from a
file and to refresh a grafts structure.
If replacing an already existing graft in the grafts map, then we need
to free the previous `git_commit_graft` structure.
Currently, we expose the function `git_repository_shallow_roots` to get
all grafted roots of the repository. This already paints us into a
corner, though, as we certainly need to experiment with some
functionality of the grafting mechanism before we can happily expose
some of its functionality. Most importantly, we need to get right when
to refresh grafts and when not.

Thus, this commit removes the public function with no public
replacement. We should first try and see what usecases people come up
with to e.g. expose the `git_grafts` mechanism directly in the future
or do something different altogether. Instead, we provide an internal
interface to get weak pointers to the grafting structs part of the
repository itself.
@lya001 lya001 closed this Aug 31, 2022
@lya001
Copy link
Contributor Author

lya001 commented Aug 31, 2022

Wrong branch

@lya001
Copy link
Contributor Author

lya001 commented Aug 31, 2022

Published again in #6396

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants