13

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 >.

arthur doe
  • 281
  • 1
  • 2
  • 6
  • 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... – arthur doe May 09 '17 at 21:23
  • 1
    @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'? – user2561747 Jun 27 '17 at 00:25
  • @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... – torek Jun 27 '17 at 00:33

5 Answers5

15

Format is YYYY-MM-DD

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

arthur doe
  • 281
  • 1
  • 2
  • 6
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.

Maxim Mazurok
  • 3,856
  • 2
  • 22
  • 37
3

I used:

--shallow-since="3 years"

and it worked fine.

Tom Hale
  • 40,825
  • 36
  • 187
  • 242
2

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.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
0
--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

wongoo
  • 566
  • 4
  • 7