7

I'm new to Git. Starting work on any project seems to start with a "git clone". But this seems to take a long time - much longer than the equivalent "svn checkout". Is this because the entire history of the project since the dawn of time is being copied? Is it possible to skip the history, and just get the latest files (but retain repository information, allowing future pulls etc).

Steve Bennett
  • 114,604
  • 39
  • 168
  • 219
  • 1
    How do you know that the SVN checkout would have taken less time? – Igor Zinov'yev Sep 03 '11 at 13:42
  • 1
    @Igor `svn checkout` copies only the head version of the repository, `git clone` copies all the history, so usually it take more time – Yuras Sep 03 '11 at 13:46
  • 1
    I'd like to point out that unlike SVN checkout, you only have to do this once, ever. You can create all the branches you want, make all the changes, etc. with that single clone. Branching with SVN typically requires another checkout, which copies all the files yet again. – Andrew T Finnell Sep 03 '11 at 13:46
  • 5
    git clones are orders of magnitude faster if you can clone over the `git://` protocol as opposed to `http[s]://`. Also, regardless of the time it takes to check out the entire project's history, in my experience it *always*, **always** pays off to have the entire project history locally. – Chris Sep 03 '11 at 13:53
  • Chris, I'm using SSH (github). How does that compare? – Steve Bennett Sep 04 '11 at 02:01
  • Thanks for the comments, all. One thing I had overlooked was that that although the initial clone is slow, subsequent operations are much faster. – Steve Bennett Sep 04 '11 at 02:02

2 Answers2

20

You can use git clone --depth=$NUM_REVISIONS, which has the following caveats:

Create a shallow clone with a history truncated to the specified number of revisions. A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches.

Mark Rushakoff
  • 249,864
  • 45
  • 407
  • 398
  • Remember that the depth is measured from the current state of the repo. As more commits are added to that repo, the depth you need to `fetch` to catch up will vary. So if you use a shallow clone, don't make it too shallow; or check how deep your start commit is within the repo before the next `fetch/pull`. – Philip Oakley Sep 03 '11 at 15:11
  • 2
    The inability to 'push' is crippling, and amounts to doing the equivalent of 'svn export' rather than 'svn checkout'. So I guess the answer is "no" - there's no way way to quick clone. – Steve Bennett Sep 04 '11 at 01:58
5

No, it's not possible. If you want to participate in a repository's history, you must have the entire history to build from. While it does take a bit longer than an SVN checkout, it's still quite fast unless you're doing it over a slow connection and/or have a really huge project.

Ryan Stewart
  • 126,015
  • 21
  • 180
  • 199
  • Do you know if that limitation is fundamental to the way Git works? If so, what's the reason? It's not intuitive to me (yet). – Steve Bennett Sep 04 '11 at 01:46
  • (Is it that since Git is *distributed* VC, it doesn't allow you to treat the upstream repository as the definitive source of truth - you have to have all the truth locally.) – Steve Bennett Sep 04 '11 at 01:57
  • I'm afraid I don't know the details. I can't think of a convincing reason myself. I just know what it says in the docs and what happens when you try to push from a shallow clone. – Ryan Stewart Sep 04 '11 at 02:44
  • @Steve, `darcs`, other distributed VC system, allows "lazy" clone, so the limitation is somewhere else. It is more likely that the limitation is that `git` uses snapshot-based history model (http://en.wikipedia.org/wiki/Comparison_of_revision_control_software#Technical_information) – Yuras Sep 04 '11 at 13:04
  • that is no longer true, see stackoverflow.com/a/21217267/1986995 – freeforall tousez Feb 15 '15 at 15:26