10GB git? about thinstation

[Thinstation]

That's constructive in a very minimalist sort of way, I suppose. I'm going to close this issue for now until more evidence surfaces about the negative impact of my approach.

[KingOfDos]

Sorry for being quite 'minimalistic' when I'd open the ticket. Maybe a bit of compensation for the 10GB download on a very expensive dialup line in a very poor 3rd world country.

Thin? It's becoming ThickStation.

---

Current version, after 'git clone'
$ ls -lh .git/objects/pack/pack-5a699126ca9111a50668de3ab4a3a648fb537648.pack
-r--r--r-- 1 user group 9.0G Dec 7 19:34 .git/objects/pack/pack-5a699126ca9111a50668de3ab4a3a648fb537648.pack

---

The version of:
drwxr-xr-x 5 user group 4096 Apr 19 2014 .

$ ls -lh .git/objects/pack/pack-ca7317605353de4eaab878de87c882a12b50d096.pack
-r--r--r-- 1 user group 2.5G Apr 19 2014 .git/objects/pack/pack-ca7317605353de4eaab878de87c882a12b50d096.pack

---

Limiting the current version:
$ git clone --depth 1 https://github.com/Thinstation/thinstation.git
Cloning into 'thinstation'...
remote: Counting objects: 9493, done.
remote: Compressing objects: 100% (7037/7037), done.
remote: Total 9493 (delta 1243), reused 8017 (delta 947)
Receiving objects: 100% (9493/9493), 1.08 GiB | 1.45 KiB/s, done.
Resolving deltas: 100% (1243/1243), done.
Checking out files: 100% (7672/7672), done.

$ ls -lh .git/objects/pack/pack-de49c7b2cc77f1375d456bbb476e43f78b83d146.pack
-r--r--r-- 1 user group 1.1G Dec 10 19:01 .git/objects/pack/pack-de49c7b2cc77f1375d456bbb476e43f78b83d146.pack

The entire git-repo with --depth 1 is:
$ du -sh 3_depth1_original/
2.3G 3_depth1_original/

---

The solution is something close to --cached --ignore-unmatch, for example:
http://stackoverflow.com/questions/11050265/remove-large-pack-file-created-by-git
3rd party packages have their own repositories and version control / legal tracability.

Seems to me that Thinstation wants to provide a fully working build-env (great!). But, your git repository should only contain Thinstation. Not Gnome, XFCE.... etc.
imho...

If Thinstation continues this way:
Apr 2014, Dec 2014... 9GB - 2.5GB = 6.5GB growth in ~9 months.
That's a 0.72GB/month increase.
End of 2015, the pack file will be: 9 + 8.64 = 17.64GB...

I don't think Thinstation is responsible for that ammount of LOC. You wish! ;-]

I guess. Create a repository without 3rd party stuff. Add live/recent 3rd party stuff to it, and never use that branch again? At least something with a 'clean' and 'dirty' repo (or branch in a), to isolate 3rd party stuff (I'm not a git guru, just a regular user. I've never seen anything like this before). Or write some download script, to grab all files from some place outside the repository (so it won't poisen the repository again). That script is property of Thinstation, so is allowed within in git.

Wonder what a git-guru would do in this situation.

[Thinstation]

I think you are a little confused about how opensource licenses work. I
only have opensource binaries in archives in my git. That is allowed. I
chose to use git exactly as it was meant to be used.....keeping track of
the history of the project. It does not matter at all how big the repo
gets, only how big the checkout is. Thinstation is a framework, so yes, the
tool comes with a lot more than you might need, but that's so you can make
thin and light images. It itself does not need to be thin, but it's not
bloated either. This project is aimed at users with minimal Linux
experience, so asking them to wait for software to compile is pretty much
out, unless it's proprietary third party, in which case, there is no other
choice.

I am sorry to hear that you only have dial-up. That's must really limit
your access to every distribution.
On Dec 10, 2014 11:14 AM, "Roel Jansen" [email protected] wrote:

Sorry for being quite 'minimalistic' when I'd open the ticket. Maybe a bit
of compensation for the 10GB download on a very expensive dialup line in a
very poor 3rd world country.

Thin? It's becoming ThickStation.

Current version, after 'git clone'
ls -lh .git/objects/pack/pack-5a699126ca9111a50668de3ab4a3a648fb537648.pack

-r--r--r-- 1 user group 9.0G Dec 7 19:34

.git/objects/pack/pack-5a699126ca9111a50668de3ab4a3a648fb537648.pack

The version of:
drwxr-xr-x 5 user group 4096 Apr 19 2014 .

ls -lh .git/objects/pack/pack-ca7317605353de4eaab878de87c882a12b50d096.pack
-r--r--r-- 1 user group 2.5G Apr 19 2014

.git/objects/pack/pack-ca7317605353de4eaab878de87c882a12b50d096.pack

Limiting the current version:
git clone --depth 1 https://github.com/Thinstation/thinstation.git

Cloning into 'thinstation'...
remote: Counting objects: 9493, done.
remote: Compressing objects: 100% (7037/7037), done.
remote: Total 9493 (delta 1243), reused 8017 (delta 947)
Receiving objects: 100% (9493/9493), 1.08 GiB | 1.45 KiB/s, done.
Resolving deltas: 100% (1243/1243), done.
Checking out files: 100% (7672/7672), done.
ls -lh .git/objects/pack/pack-de49c7b2cc77f1375d456bbb476e43f78b83d146.pack

-r--r--r-- 1 user group 1.1G Dec 10 19:01
.git/objects/pack/pack-de49c7b2cc77f1375d456bbb476e43f78b83d146.pack

The entire git-repo with --depth 1 is:
du -sh 3_depth1_original/

2.3G 3_depth1_original/

The solution is something close to --cached --ignore-unmatch, for example:

http://stackoverflow.com/questions/11050265/remove-large-pack-file-created-by-git
3rd party packages have their own repositories and version control / legal
tracability.

Seems to me that Thinstation wants to provide a fully working build-env
(great!). But, your git repository should only contain Thinstation. Not
Gnome, XFCE.... etc.
imho...

If Thinstation continues this way:
Apr 2014, Dec 2014... 9GB - 2.5GB = 6.5GB growth in ~9 months.
That's a 0.72GB/month increase.
End of 2015, the pack file will be: 9 + 8.64 = 17.64GB...

I don't think Thinstation is responsible for that ammount of LOC. You
wish! ;-]

I guess. Create a repository without 3rd party stuff. Add live/recent 3rd
party stuff to it, and never use that branch again? At least something with
a 'clean' and 'dirty' repo (or branch in a), to isolate 3rd party stuff
(I'm not a git guru, just a regular user. I've never seen anything like
this before). Or write some download script, to grab all files from some
place outside the repository (so it won't poisen the repository again).
That script is property of Thinstation, so is allowed within in git.

Wonder what a git-guru would do in this situation.

—
Reply to this email directly or view it on GitHub
#54 (comment)
.

[gcscaglia]

Sorry for necroing this issue, but what KingOfDos means is that instead of versioning packages binaries, you should version scripts which downloads and extracts the packages (from their repository, specifying the version; This way you can still track changes), and have their extracted contents in your .gitignore.

That's how dependency management works when you use things like maven for java, pip for python, gems for ruby, etc. Since on Thinstation case there is no equivalent, writing you own is the way to go.

Currently, thinstation .gitignore files are, at best, insufficient. As soon as you run setup-chroot, git status reports lots of untracked files; This shouldn't be the case.

[Thinstation]

That is a common anti-pattern, but I do not wish to sustain it.

[gcscaglia]

I see, you do understand what we mean, but you do not agree with it. That's a perfectly fine view point; there is more than one way to do things. Never mind me then.

But what about the current .gitignore? Since a fresh setup-chroot already has lots of untracked files, It becomes quite cumbersome to keep track of what we actually added. Is there a particular rationale and/or workflow which justifies the current .gitignore?

[Doncuppjr]

blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px #715FFA solid !important; padding-left:1ex !important; background-color:white !important; } I never really intended for such a thing to exist, it was a contribution that didn't get in my way, so it was allowed. I run clean_chroot before doing a status or commit. A time consuming operation, but when you need orientation, it works. Very destructive, use at your own risk. Sent from Yahoo Mail for iPhone On Friday, June 23, 2017, 9:34 AM, gcscaglia <[email protected]> wrote: I see, you do understand what we mean, but you do not agree with it. That's a perfectly fine view point; there is more than one way to do things. Never mind me then. But what about the current .gitignore? Since a fresh setup-chroot already has lots of untracked files, It becomes quite cumbersome to keep track of what we actually added. Is there a particular rationale and/or workflow which justifies the current .gitignore? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[gcscaglia]

I see, that certainly works too, despite the caveats you already mentioned.

Never mind that as well. Ty for your attention.

[Doncuppjr]

blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px #715FFA solid !important; padding-left:1ex !important; background-color:white !important; } Np, feel free to improve .gitignore generation logic.  Sent from Yahoo Mail for iPhone On Friday, June 23, 2017, 9:50 AM, gcscaglia <[email protected]> wrote: I see, that certainly works too, despite the caveats you already mentioned. Never mind that as well. Ty for your attention. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.