Support for shallow-since clones/fetches#7093
Conversation
There was a problem hiding this comment.
Now that we have shallow_since, depth is no longer the only variable that determines whether a fetch is shallow or not. Consider clone.c: if (!options.fetch_opts.depth)
options.fetch_opts.download_tags = GIT_REMOTE_DOWNLOAD_TAGS_ALL;
There was a problem hiding this comment.
So we could have a new function that takes git_fetch_options and returns true/false if the fetch would be shallow.
There was a problem hiding this comment.
Tried this, but it's difficult to get a combination of name and behaviour. You only know if the fetch "would be shallow" if you know how many commits there are, which we don't. An "unshallow" operation is largely indistinguishable from a shallow fetch with a large depth.
|
|
||
| if (wants->depth > 0) { | ||
|
|
||
| if (wants->shallow_since != GIT_FETCH_SINCE_UNSPECIFIED) { |
There was a problem hiding this comment.
Should we do this argument validation up in git_fetch_negotiate?
There was a problem hiding this comment.
Can't see a better location that would definitely be hit by every codepath.
…or consistency with "depth" - and create a separate enum for it.
|
Renamed the detault value of shallow_since to "GIT_FETCH_SINCE_FULL", and change the value to zero. This makes its usage more consistent with the usage of "depth". |
malcolmwood76
changed the title
malcolmwood76
changed the title
|
LGTM |
3 participants
Support for the Git "shallow-since" option for clone/fetch. In the Git protocol the term "deepen-since" is used. The implementation below works well when the specified date is older than the newest commit - i.e. when there are commits to fetch.
The Git command-line gives a very poor error when the date specified is newer than newest last commit - i.e. no commits to fetch. The message is "error processing shallow info: 4".
Unfortunately, with this change libgit2 gives an even poorer error (GIT_EEOF). See the function: test_online_shallow__clone_since_recent.
With packet tracing enabled in the Git command-line I can see a "0002" message arriving after the one about "refs/tags/nearly-dangling". But in my test this doesn't seem to arrive, and we get GIT_EEOF in the call to recv_pkt at smart_protocol.c:447 instead.
fixes #6611