many files, simple history

short version: will git handle large number of files efficiently if
the history is simple and linear, i.e., without merges?

longer version: i'm considering using git to keep track of my
installed user programs/files on my linux machine, mainly because i
want to be able to uninstall software cleanly and completely (i almost
always build from source code and install in non-standard locations).
so i would want to use git to keep track of every program i install or
uninstall. this way, i could go back and uninstall a program simply by
finding the commit when it was installed, get the list of files that
were added as a result, and remove them (and of course, commit the
removals into git so i can always undo the uninstall too!)

so the history stored in git will be linear and consist of file
additions and removals. but this will potentially involve many files.
will git be able to handle this (as yet hypothetical) situation
efficiently?

/ali

On Thu, May 13, 2010 at 21:57, Ali Tofigh [off-list ref] wrote:

(i almost
always build from source code and install in non-standard locations).

It would make a lot more sense to use a package manager.

You might find that Arch Linux's `pacman' provides everything that you
need; it's really easy to define your own packages and build from
source, allowing pacman to manage dependencies, locate which package
owns which file, and upgrade/remove packages.

I bet gentoo's `emerge' would also be viable.

On Thu, May 13, 2010 at 10:57:22PM -0400, Ali Tofigh wrote:

short version: will git handle large number of files efficiently if
the history is simple and linear, i.e., without merges?

Short answer: large number of files, yes, large files, not really. The
shape of history is largely irrelevant.

Longer answer:

Git separates the conceptual structure of history (the digraph of
commits, and the pointers of commits to trees to blobs) from the actual
storage of objects representing that history. Problems with large files
are usually storage issues. Copying them around in packfiles is
expensive, storing an extra copy in the repo is expensive, trying deltas
and diffs is expensive. None of those things has to do with the shape of
your history. So I would expect git to handle such a load with a linear
history about as well as a complex history with merges.

For large numbers of files, git generally does a good job, especially if
those files are distributed throughout a directory hierarchy. But keep
in mind that the git repo will store another copy of every file. They
will be delta-compressed between versions, and zlib compressed overall,
but you may potentially be doubling the amount of disk space required if
you have a lot of uncompressible binary files.

For large files, git expects to be able to pull each file into memory.
Sometimes two versions if you are doing a diff. And it will copy those
files around when repacking (which you will want to do for the sake of
the smaller files). So files on the order of a few megabytes are not a
problem. If you have files in the hundreds of megabytes or gigabytes,
expect some operations to be slow (like repacking).

Really, I would start by just "git add"-ing your whole filesystem, doing
a "git repack -ad", and seeing how long it takes, and what the resulting
size is.

-Peff

On Fri, May 14, 2010 at 00:05, Jeff King [off-list ref] wrote:

On Thu, May 13, 2010 at 10:57:22PM -0400, Ali Tofigh wrote:

quoted

short version: will git handle large number of files efficiently if
the history is simple and linear, i.e., without merges?

Short answer: large number of files, yes, large files, not really. The
shape of history is largely irrelevant.

thank you for the explanation. I will start using git for managing my
installed programs and will try to  report back to this list about my
experience.

/ali

Longer answer:

Git separates the conceptual structure of history (the digraph of
commits, and the pointers of commits to trees to blobs) from the actual
storage of objects representing that history. Problems with large files
are usually storage issues. Copying them around in packfiles is
expensive, storing an extra copy in the repo is expensive, trying deltas
and diffs is expensive. None of those things has to do with the shape of
your history. So I would expect git to handle such a load with a linear
history about as well as a complex history with merges.

For large numbers of files, git generally does a good job, especially if
those files are distributed throughout a directory hierarchy. But keep
in mind that the git repo will store another copy of every file. They
will be delta-compressed between versions, and zlib compressed overall,
but you may potentially be doubling the amount of disk space required if
you have a lot of uncompressible binary files.

For large files, git expects to be able to pull each file into memory.
Sometimes two versions if you are doing a diff. And it will copy those
files around when repacking (which you will want to do for the sake of
the smaller files). So files on the order of a few megabytes are not a
problem. If you have files in the hundreds of megabytes or gigabytes,
expect some operations to be slow (like repacking).

Really, I would start by just "git add"-ing your whole filesystem, doing
a "git repack -ad", and seeing how long it takes, and what the resulting
size is.

-Peff

On Thu, May 13, 2010 at 23:27, Michael Witten [off-list ref] wrote:

On Thu, May 13, 2010 at 21:57, Ali Tofigh [off-list ref] wrote:

quoted

(i almost
always build from source code and install in non-standard locations).

It would make a lot more sense to use a package manager.

you're probably right, but if i want to keep up with all my everyday
obligations, then i have to chose my battles carefully. for many
tasks, there are specialized tools that can be used, but these always
come at the expense of having to learn them. and if those tasks aren't
performed on a daily basis, then i don't stand a chance at remembering
what i've learned and i have to relearn them over and over again.

/ali

You might find that Arch Linux's `pacman' provides everything that you
need; it's really easy to define your own packages and build from
source, allowing pacman to manage dependencies, locate which package
owns which file, and upgrade/remove packages.

I bet gentoo's `emerge' would also be viable.