0

My question is simple:

I have a project with a local Git repo, and I have pushed it to Bitbucket. What I'm trying to do is to remove the local repo and commit my project just to the remote repo, so that I don't have a double-sized project on my hard drive.

Is there any good solution for this?

More details

I'm worrying that the .git folder might drain my hard drive. Creating my local Git repo keeps all the files, and I ended up creating a project that's twice as big. The app deals with media files...it's 500 MB without Git.

CstLex
  • 1
  • 1
  • 4
  • 2
    *So that I don't have double sized project in my hard drive* Are you under the impression that www.bitbucket.org takes up space on your hard drive? – ta.speot.is Jul 26 '13 at 07:52
  • 1
    I'm worrying about that .git folder might drain my hard drive. – CstLex Jul 26 '13 at 07:57
  • Creating local git keeps all files and ended up creating project double sized... – CstLex Jul 26 '13 at 07:58
  • 2
    @user2621772: It is the **point** of using Git (being a [DVCS](http://en.wikipedia.org/wiki/Distributed_version_control_system)) to have the whole repo on every clone. If you do not want that, you should probably use a centralized VCS (like SVN) instead. – Nevik Rehnel Jul 26 '13 at 08:05
  • *I'm worrying about that .git folder might drain my hard drive.* [A git repository of Firefox is 200 MB](http://bluishcoder.co.nz/2011/02/10/git-conversion-of-mozilla-central.html). Your project is not as big as Firefox, and never will be. – ta.speot.is Jul 26 '13 at 08:08
  • 1
    well...the app is dealing with media files... it's 500mb without git... – CstLex Jul 26 '13 at 08:20
  • @NevikRehnel thx I'll consider that – CstLex Jul 26 '13 at 08:22
  • 1
    What your app is dealing with does not matter at all and does not increase your repository size. But if you're checking in big binary blobs you're doing it wrong. Git was designed for source code. – Marco Jul 26 '13 at 11:20

2 Answers2

0

Creating local git keeps all files

Yes, that's what git does. From a cursory Google search:

Rather than a single, central repository on which clients synchronize, each peer's working copy of the codebase is a bona fide repository ... [this] results in some important differences from a centralized system

...

  • Each working copy effectively functions as a remote backup of the codebase and of its change-history, protecting against data loss

...

  • Allows users to work productively when not connected to a network.

  • Makes most operations much faster.

  • Allows private work, so users can use their changes even for early drafts they do not want to publish.

...

  • Avoids relying on one physical machine as a single point of failure.

As for your "problem"

I'm worrying about that .git folder might drain my hard drive.

A git repository of Firefox is 200 MB. Consider the size of your project relative to Firefox, and then be prepared to set aside a generous ten thousand, two-hundred and forty kilobytes for your project's git repository.

Community
  • 1
  • 1
ta.speot.is
  • 26,914
  • 8
  • 68
  • 96
0

I'd like to point out a few things:

  1. Git can only make commits to a local repo.
  2. Git compresses files in its repo.
  3. Git is ill-suited for versioning binaries.

See each section below for full explanation.

Git can only make commits to a local repo

There is no way I know of in Git to make a commit directly to a remote repository, without having to go through a local one first. That's not how Git works. If you want to make commits, I think you can only do so with a local repository.

Git compresses files in its repo

Files under the .git directory are compressed, so the Git repo at the .git directory will probably be much smaller than your working copy checkout, especially if it's just full of text and not binary files (more on binary files later). At work, I use a Git repo that's about 300 MB, but the working copy is around 2.5 GB, so the actual repo itself is much smaller in comparison.

Compression settings for Git

You can configure Git to use different compression levels:

core.compression

An integer -1..9, indicating a default compression level. -1 is the zlib default. 0 means no compression, and 1..9 are various speed/size tradeoffs, 9 being slowest. If set, this provides a default to other compression variables, such as core.loosecompression and pack.compression.

core.loosecompression

An integer -1..9, indicating the compression level for objects that are not in a pack file. -1 is the zlib default. 0 means no compression, and 1..9 are various speed/size tradeoffs, 9 being slowest. If not set, defaults to core.compression. If that is not set, defaults to 1 (best speed).

pack.compression

An integer -1..9, indicating the compression level for objects in a pack file. -1 is the zlib default. 0 means no compression, and 1..9 are various speed/size tradeoffs, 9 being slowest. If not set, defaults to core.compression. If that is not set, defaults to -1, the zlib default, which is "a default compromise between speed and compression (currently equivalent to level 6)."

Note that changing the compression level will not automatically recompress all existing objects. You can force recompression by passing the -F option to git-repack(1).

You can read more about Git packfiles from the free online Pro Git book.

Git is ill-suited for versioning binaries

Finally, the original poster makes this comment:

well...the app is dealing with media files... it's 500mb without git

Git is not well-suited to versioning binary files (like media files, like pictures, videos, audio clips, etc), because Git can't keep text diff deltas of changes to them like it can with text files, it actually has to keep each version of a binary in its entirety every time you make changes to it.

So if you have a 1 MB picture file called logo.jpg, and you make a small change to it, Git would have to store the whole logo.jpg file all over again, adding another 1 MB to your repository.

Solution 1: Remove binaries with git filter-branch

If your media files don't actually need to be versioned in Git, consider removing them from your repository using git filter-branch. You can read more about this option at the official Linux Kernel Git documentation for git filter-branch and at the "The Nuclear Option: filter-branch" of the free online Pro Git book.

Solution 2: use 3rd party services for media files instead

GitHub makes this suggestion for dealing with large media files:

Binary media files don't get along very well with Git. For these files it's usually best to use a service specifically designed for what you're using.

For large media files like video and music you should host the files yourself or using a service like Vimeo or Youtube.

For design files like PSDs and 3D models, a service like Dropbox usually works quite nicely. This is what GitHub's designers use to stay in sync; Only final image assets are committed into our repositories.

More about Git and versioning binary files

You can learn more about Git and versioning binaries in these other Stack Overflow questions:

  1. Managing large binary files with git.
  2. git with large files.
Community
  • 1
  • 1