Re: GSoC - Some questions on the idea of

One question,  can anyone help me clear?

My .git/objects has 3 blobs, a, b, and c. a is a unique file, b and c
two sequential versions of the same file. When I run "git gc", what
exactly happens here, e.g., how exactly git (in the latest version)
delta compresses-the blobs here?

Any help will be appreciated.

Bo

On Sun, Apr 1, 2012 at 12:22 AM, Nguyen Thai Ngoc Duy [off-list ref] wrote:

On Sun, Apr 1, 2012 at 4:27 AM, Bo Chen [off-list ref] wrote:

quoted

quoted

Who decides bigness:
Bigness seems to be relative to system resources.  Does the user crunch the
numbers to determine if a file is big-file, or does git?  If the numbers are
relative then should git query the system and make the determination?
 Either way, once the system-resources are upgraded and formerly "big-files"
are no longer considered "big" how is the previous history refactored tot
behave "non-big-file-like"?  Conversely, if the system-resources are
re-distributed so that formerly non-big files are now relatively big (ie,
moved from powerful central server login to laptops), how is the history
refactored to accommodate the newly-relative-bigness?

In common sense, a file of tens of MBs should not be considered as a
big file, but a file of tens of GBs should definitely be considered as
a big file. I think one simple workable solution is to let the user
set the threshold of the big file.

We currently have core.bigFileThreshold = 512MB.

quoted

One complicate but intelligent
solution is to let git auto-config the threshold by evaluating current
computing resources in the running platform (a physical machine or
just a VM). As to the problem of migrating git in different platforms
which equip with different computing power, the git repo should also
keep tract of under what big file threshold a specific file is
handled.

--
Duy