Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Repo size is huge! #389

Closed
rht opened this issue Jan 28, 2021 · 10 comments
Closed

Repo size is huge! #389

rht opened this issue Jan 28, 2021 · 10 comments
Assignees

Comments

@rht
Copy link
Contributor

rht commented Jan 28, 2021

For an unknown reason, the .git/ objects are huge, ~263 MB. But the files elsewhere that are not in .git/ amount to probably about ~2 MB at most. Why is this the case? It took me a while to clone the repo. Is it possible to rewrite the history of this repo to remove the huge object? I don't know what it is.

@Libbum
Copy link
Member

Libbum commented Jan 28, 2021

It's the gh-pages branch which stores all of the documentation. We've been working on cutting it down but have not had complete success with that.

@rht
Copy link
Contributor Author

rht commented Jan 28, 2021

I see. I suppose there is no way around it other than to softly warn people of the fetch size if they do normal git clone, somewhere in the readme? According to https://stackoverflow.com/questions/1778088/how-do-i-clone-a-single-branch-in-git, git clone <url> --single-branch is an option.

@Datseris
Copy link
Member

Sure, pointing to cloning master is reasonable. However I don't think the docs size can be cut down to more than what they are now, it's already pretty impressive.

@Libbum
Copy link
Member

Libbum commented Jan 28, 2021

Not a bad idea. I'll put something similar in the Developer Documentation.

@rht
Copy link
Contributor Author

rht commented Sep 21, 2022

After some discussion in projectmesa/mesa-geo#101, we concluded that example videos for Mesa-Geo can be put in a separate GH repo containing just the videos. And the tutorial can simply link to the raw files of this repo.

Maybe this method can be used to streamline the git clone command in the developer doc? This way, you can also retain the https://juliadynamics.github.io/Agents.jl URL, instead of having the GH pages under different URL.

@Datseris
Copy link
Member

https://juliadynamics.github.io/Agents.jl/stable/devdocs/#Cloning-the-repository-1

At the moment we simply advise people that want to get into the development of Agents.jl to just do a shallow clone. All the video files are in a different branch gh-pages, so the main branch is practically just text.

I prefer this approach much more. Linking videos defies one of (my) principles of good documentation: examples must be run, not written. Letting the code put them where they should be is more future proof and will lead to less broken pages.

@rht
Copy link
Contributor Author

rht commented Sep 21, 2022

I'm aware of that devdocs content, and hence I mentioned it.

At the moment we simply advise people that want to get into the development of Agents.jl to just do a shallow clone.

This is, however, a gotcha. Most other projects are cloned without the --single-branch flag, as most would expect to just do git clone. Some people might want to clone the repo without an immediate goal of contributing, so that they can read the repo code locally. And so on.

@rht
Copy link
Contributor Author

rht commented Sep 21, 2022

To clarify, most people would do a vanilla git clone without --single-branch the repo immediately before anything else, because this is what is expected in most projects. And if people are cloning the repo just for reading, they wouldn't have read the developer doc in advance.

@Datseris
Copy link
Member

Yes, of course, everything you say is valid! One has to make a decision about this trade-off: future stability of documentation and less development effort to create the docs, or the users that don't see this dev page (which is the majority) downloading a large repo.

@Datseris
Copy link
Member

(I should say, I used to have several repos that followed this approach: upload videos elsewhere and link them. It really became a pain in the ass over time to maintain this.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants