Sebastian Slutzky
Sebastian Slutzky

Reputation: 379

What's the alternative to git --shallow-since using git clone depth

The git server I am cloning does not support shallow-since. When I try to do so, I get the following error:

fatal: Server does not support --shallow-since

I don't mind using git clone -depth=N instead, but how can I determine the N for my commit?

Upvotes: 1

Views: 1263

Answers (1)

torek
torek

Reputation: 488193

Technically, these are different:

  • --shallow-since=date obtains commits whose commit-timestamp is later than (and perhaps equal to, boundaries are hard 😀) the given timestamp;
  • --depth=number obtains commits whose counting-depth from names (branch names, tag names, and any other names you tell Git to use) is within the given number of steps.

That is, consider a Git repository with the following commits:

A--B--C   <-- master
    \
     D--E--F--G   <-- develop

Suppose that the dates for C, E, F, and G are all this year, and A, B, and D are all the previous year. If you do:

git clone --shallow-since=<this year> --no-single-branch

you'll get commits C and E-F-G like this:

...--C   <-- origin/master

...--E--F--G  <-- origin/develop

However, if you do:

git clone --depth=2 --no-single-branch you will get:

...--B--C   <-- origin/master

...--F--G   <-- origin/develop

i.e., two commits from each name. (There's no linkage from G back to B as that requires going four steps back from G to reach D, and we told Git to cut things off after two steps.)

Since --depth enables --single-branch by default, this peculiarity tends to get hidden: if you're only telling your clone to make an origin/master, it does not matter if the same depth would have applied to each other name too. Adding the --no-single-branch option makes the difference much clearer.

In any case, if you don't have direct access to the server, the obvious way to calculate the depth is to make a full (but optionally, single-branch) clone, then examine the committer dates in the repository you now have locally. You can then count the revisions from the last date you want to the branch tip, which tells you how many commits to clone.

Of course, by this time, you have a full clone, so you might as well just use it.

A workable alternative is to make an initial clone with some fixed --depth. Then, inspect the earliest commit's committer timestamp. If that date is after your cutoff, use git fetch --deepen (or --depth again) to deepen the shallow clone. Repeat the inspect-and-deepen until the repository is deep enough.

(The number of commits to clone initially, then to add per fetch, depends on how long it takes to bring over each group of commits, vs the overhead involved in setting up another round of git fetch, so there's no obvious Right Number to use.)

Upvotes: 3

Related Questions