Git cannot create shallow-since locally

Question

I am trying to create a --shallow-since working clone from a local bare clone but it keeps pulling everything. --depth=N works fine.

I'm thinking the issue is I'm using the wrong format? I've tried searching but no where does it explicitly say what format < date > is supposed to be for --shallow-since=< date >.

Duncandunce

Hmm, what you say makes sense... It seems to wok consistently when I get a shallow repo using depth=1 so thanks for that. That being said I'm experience some weird behavior where if I fetch the initial fetch (after git init and adding the remote) with shallow-since it will work for some dates but not for closer dates beyond a point. I just assumed my formatting was wrong but I guess I need a shallow working dir first... – Duncandunce

@torek git clone --shallow-since=YYYY-MM-DD worked just fine to clone a new local repo for me.. why do you say it 'deepens or shortens the shallowness of an existing clone. It does not make a new clone be a shallow clone'? – Dipetalous

@user2561747: the OP was trying to take an existing non-shallow clone and turn it into a shallow clone, if I remember right. But yes, the text in the comment above is pretty misleading now (I guess some context has gone away). I think I will just delete that comment... – Bauble

Answer 1

Format is YYYY-MM-DD

See above comment for what confused me and how that confusion was resolved.

Duncandunce

Just for the record: You can also do thinks like 1week 3month or 2years – Allopathy

Answer 2

I used:

--shallow-since="3 years"

and it worked fine.

Puebla

Answer 3

Using UNIX timestamp:

git fetch upstream master --shallow-since=1589324214

on git version 2.26.2.windows.1 and in GitHub actions CI also works just fine.

Sunroom

Answer 4

While the date format is indeed, for instance, YYYY-MM-DD, "git fetch --shallow-since=<cutoff>" had a problem:

If you specify a cut-off point that is newer than the existing history, it used to end up grabbing the entire history.
Such a request now errors out with Git 2.19 (Q3 2018).

See commit e34de73 (26 May 2018) by Nguyễn Thái Ngọc Duy (pclouds).
^{(Merged by Junio C Hamano -- gitster -- in commit 208ee59, 25 Jun 2018)}

upload-pack: reject shallow requests that would return nothing

Shallow clones with --shallow-since or --shalow-exclude work by running rev-list to get all reachable commits, then draw a boundary between reachable and unreachable and send "shallow" requests based on that.

The code does miss one corner case: if rev-list returns nothing, we'll have no border and we'll send no shallow requests back to the client (i.e. no history cuts).
This essentially means a full clone (or a full branch if the client requests just one branch).
One example is the oldest commit is older than what is specified by --shallow-since.

To avoid this, if rev-list returns nothing, we abort the clone/fetch.
The user could adjust their request (e.g. --shallow-since further back in the past) and retry.

Another possible option for this case is to fall back to a default depth (like depth 1).
But I don't like too much magic that way because we may return something unexpected to the user. If they request "history since 2008" and we return a single depth at 2000, that might break stuff for them.
It is better to tell them that something is wrong and let them take the best course of action.

Erlineerlinna

Answer 5

--shallow-since=<date>
    Deepen or shorten the history of a shallow repository to include all reachable commits after <date>.

The format of the date is yyyy-MM-ddTHH:mm:ss, eg: 2020-04-13T11:01:01

Elbert