project-navigation
Personal tools

Author Topic: The GIT problem::Initial clone  (Read 3528 times)

Offline Duke

  • Administrator
  • PHALANX veteran
  • *****
  • Posts: 1037
    • View Profile
The GIT problem::Initial clone
« on: October 07, 2010, 01:16:05 am »
- clone
The devs will sooner or later get their clone, but for a *new* contributor the 1.6 GB plus the learning of GIT is too much of a hurdle for most of the potential contributors imho.
The initial 'SVN checkout' wasn't really small either, but it was *restartable*.

Some ideas:
1. It has already been mentioned on these forums that GIT also offers a restartable version of 'clone'. If that is really equivalent to the std 'clone', it should be mentioned in a proiminent position in the docs.

2. We could split the repo 'horizontally'
By 'horizontally' I mean to strip off the history beyond version XX and keep it in a seggregated place for specialists.
I'll certainly never need any revision prior to 2.2.1 and will probably never go back beyond 2.3.
Does anyone know (or knows how to figure it out) how much the size of the repo would be reduced ?

3. split the repo 'vertically'
An old plan of mine is to make uforadiant a separate project. And I can think of more separate things.
Repo size reduction ?
« Last Edit: October 07, 2010, 01:28:23 am by Duke »

Offline H-Hour

  • Administrator
  • PHALANX Commander
  • *****
  • Posts: 1923
    • View Profile

Offline Duke

  • Administrator
  • PHALANX veteran
  • *****
  • Posts: 1037
    • View Profile
Re: The GIT problem::Initial clone
« Reply #2 on: October 08, 2010, 12:00:55 am »
TY H-Hour. I take it that the --depth is the way to go.
- Does this work for both the read-only and commitable repo ? Or is there no difference ?
- Are there any disadvantages (other than not being able to bisect back to Adam&Eve) ?
- '--depth n' is a moving target. Can we also set depth to a certain tag, eg. 2.3 ?
- There are several variants of the depth method mentioned in the thread. It wasn't clear to me exactly which method worked best ?

Offline DarkRain

  • Project Coder
  • Captain
  • ***
  • Posts: 747
    • View Profile
Re: The GIT problem::Initial clone
« Reply #3 on: October 12, 2010, 09:56:09 pm »
Ok, sorry for the late reply but my internet connection died on me again

TY H-Hour. I take it that the --depth is the way to go.
I'm not sure about that read below . . .

Quote
- Does this work for both the read-only and commitable repo ? Or is there no difference ?
- Are there any disadvantages (other than not being able to bisect back to Adam&Eve) ?
According to docs the BIG drawback would be that a shallow repo (created with --depth n) is completely push disabled, both pushin from it and to it (and see link below)
But you supposedly can download the history later using additional git fetch --depth n commands where n is the number of revs previous to the first one you have that you want to add to your repo's history (so maybe you can download the repo in 'parts')

Quote
- '--depth n' is a moving target. Can we also set depth to a certain tag, eg. 2.3 ?
Not that I know, but you can fetch a specific branch not only master (with the method using init, remote add, fetch and checkout)

Quote
- There are several variants of the depth method mentioned in the thread. It wasn't clear to me exactly which method worked best ?
Using git clone --depth n seems to have only marginal reduction of the repo weight according to this blog (I'll confirming that soon)
While using the method of: init the repo, add the wanted branch, fetch with --depth n and then checkout the branch makes a BIG difference in weight (I can confirm downloading aprox. 590 mb for master a while ago using this one) (so if you are only beta testing you can get the latest rev this way)

So I question (mostly myself):
-Can you get the whole repo branch by branch using this method?
-If you can, can you fetch the diffrent branches without history and then get the history using an additional git fetch --depth n (where n is a number that will get you the whole history)?
-Is it really needed to fetch all the branches anyway?

Besides that what about the idea in that blog entry about tarballing the repo? That would be restartable tough I don't expect it to shrink the ufoai repo by one gig.

Also can branches older than the latest release be 'hidden' fron a clone the way the data_source is? Would that reduce the download size?

I have other ideas but I have to go now, will report about the shallow cloning when its complete.

Offline Mattn

  • CaveExpress
  • Administrator
  • PHALANX Commander
  • *****
  • Posts: 4830
  • www.caveproductions.org
    • View Profile
    • CaveExpress
Re: The GIT problem::Initial clone
« Reply #4 on: October 12, 2010, 10:31:35 pm »
you can also just use the rsync method to fetch the repo

Offline Duke

  • Administrator
  • PHALANX veteran
  • *****
  • Posts: 1037
    • View Profile
Re: The GIT problem::Initial clone
« Reply #5 on: October 12, 2010, 11:59:14 pm »
TY DarkRain for the elaborate answer.
Well, and the new questions you raised ;)
I understand that clone --depth n doesn't really help, so fetch --depth n *might* be the way to go ?

@Mattn:
Is rsync *fully* equivalent to clone or are there any drawbacks ?

Offline DarkRain

  • Project Coder
  • Captain
  • ***
  • Posts: 747
    • View Profile
Re: The GIT problem::Initial clone
« Reply #6 on: October 13, 2010, 05:08:26 am »
For reference: rsync method here

BTW, I ran this (out of curiosity) with --stats and --dry-run (so nothing was actually downloaded) it reports a transfered file size of 3.3 gigs so, yes, you can resume it, but you then have to download the double . . .
hard choice, isn't it?

Offline Mattn

  • CaveExpress
  • Administrator
  • PHALANX Commander
  • *****
  • Posts: 4830
  • www.caveproductions.org
    • View Profile
    • CaveExpress
Re: The GIT problem::Initial clone
« Reply #7 on: October 13, 2010, 07:31:45 am »
rsync will afaik download everything - so in the end you might be downloading more, but you can continue and abort at every time you want.

also you have to edit the repo manually after that - we could also just offer a script for that (some volunteers?) - see the rsync thread above

Offline O01eg

  • Rookie
  • ***
  • Posts: 73
    • View Profile
Re: The GIT problem::Initial clone
« Reply #8 on: October 23, 2010, 07:34:49 pm »
rsync will afaik download everything - so in the end you might be downloading more, but you can continue and abort at every time you want.
How to make shallow repository after it?