Git's object store and packing are optimized for * Expensive repo to repo bandwidth; and * Small-ish files This justifies extensive use of compression. In a multi-developer *office* with inter-repository transfers occurring over a 100Mb+ LAN, there is less reason to compress files and slow down response times. Response times suffer even more when large files are involved. However, *off-line* pack compression may still be desirable to reduce storage space. Consequently, for such a usage pa...

Add --max-pack-size parsing and usage messages. Upgrade git-repack.sh to handle multiple packfile names. Signed-off-by: Dana L. How <danahow@gmail.com> --- builtin-pack-objects.c | 9 ++++++++- git-repack.sh | 12 +++++++----- 2 files changed, 15 insertions(+), 6 deletions(-) diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c index a7b19c2..69fec34 100644 --- a/builtin-pack-objects.c +++ b/builtin-pack-objects.c @@ -15,7 +15,7 @@ #include "progress.h" s...

With --max-pack-size, generate the appropriate write limit for each object and check against it before each group of writes. Update delta usability rules to handle base being in a previously- written pack. Inline sha1write_compress() so we know the exact size of the written data when it needs to be compressed. Detect and return write "failure". Signed-off-by: Dana L. How <danahow@gmail.com> --- builtin-pack-objects.c | 134 ++++++++++++++++++++++++++++++++++++++--------- 1 files chang...

update=0 suppressed writing the final SHA-1 but was not used. Now final=0 suppresses SHA-1 finalization, SHA-1 writing, and closing -- in other words, only flush the buffer. Signed-off-by: Dana L. How <danahow@gmail.com> --- csum-file.c | 8 +++++--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/csum-file.c b/csum-file.c index 7c806ad..9913cb5 100644 --- a/csum-file.c +++ b/csum-file.c @@ -29,18 +29,20 @@ static void sha1flush(struct sha1file *f, unsigned int coun...

OpenOffice.org is looking for a new SCM (Software Configuration Management) tool, or at least was on Friday, 19 Jan 2007; see: http://blogs.sun.com/GullFOSS/entry/openoffice_org_scm One of the SCMs considered is Git. One of others is Subversion. There is a functional git tree with the entire OOo history for testing purposes that can be found at: http://go-oo.org/git. What I am concerned about is some of git benchmark results at Git page on OpenOffice.org wiki: [ message continues ]

This extension allows GNU tar to process file names in excess of the 100 characters defined by the original tar standard. It does this by faking a file, named '././@LongLink' containing the true file name, and then adding the file with a truncated name. The idea is that tar without this extension will write out a file with the long file name, and write the contents into a file with truncated name. Unfortunately, GNU tar does a lousy job at times. When truncating results in a _directory_ nam...

Hi, I'm using Git as a SVN frontend (via git-svn). Recently, I made a topic branch, I did some job on it and wish to "upload" my work (on the SVN). But, I do not want "pushing" all commits, I only want to create a single commit on the SVN, while keeping full commits on my Git repo. But I did not find how to do this. Here my story. Let's call "upstream" the local branch connected to the SVN, the raw SVN mirror branch is remotes/upstream. Now, I create a branch "topic" from "upstream" and I do jo...

If you just want to make a commit to Subversion containing all the changes on your branch, then you should be able to do this: git svn commit-diff upstream topic That will take the entire diff between upstream and your topic branch and make one commit to Subversion containing that diff. -Adam -

Thomas H

I try to use git with large blobs. Putting such blobs into pack files is a slow operation and requires lots of memory. So I take a look at the packing process. As the delta format only supports 32 bit offsets, the uncompressed blob size is limited to 4GB. The delta index has approximately the same size in memory as the uncompressed blob ((blob size)/16*(sizeof(index_entry)). git-pack-objects keep the delta index of all objects in the search window in memory. So doing a delta of 4 GB files is ...

Hi, The interesting timings, of course, would be of big blobs which are _not_ append-only, as they are more common, at least for me. Since git.git contained next to no binary blobs, this is not a good test case. Ciao, Dscho -

FYI, In case someone gets interested in addressing the warnings, here is compile result under current Cygwin. Jari ---------------------------------------------------------------------- GNU Make 3.81 gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) GIT_VERSION = 1.5.1.3 rm -f *.o mozilla-sha1/*.o arm/*.o ppc/*.o compat/*.o xdiff/*.o \ test-chmtime.exe libgit.a xdiff/lib.a rm -f git-convert-objects.exe git-fetch-pack.exe git-fsck.exe git-hash-object.exe git-i...

That's truly interesting, Andy. Thanks for the encouraging report. Please do keep us informed of anything more you conclude about this approach. I'm sure some of the experts around here can respond with the pros and cons of this technique. For my part, I wonder if it can be simplified somehow; and I suspect it doesn't work well with svn:externals that specify a particular revision. -

Just to clarify, my point was just that Andy's setup seems to assume that the externals don't specify a revision. If they do, maybe git-svn can map the externals into subprojects. Is this what you're thinking? -

That's only true when the revision is not specified in the external. The repo you track may not do that, but it's not uncommon to do so. And, as I think you're pointing out, it's the only way to get any sort of reliable information about the relationship between the parent and the external. I think it would probably be undesirable for git-svn to attempt to convert "floating" externals into well-versioned submodules, since they're not even well-versioned in the svn repo. However, handling svn ...

I don't know, but I would guess that it's no newer than externals in No, you have to manage the revision in the svn:external property Making git-svn handle svn:externals with specified revisions would be _quite_ useful. There's a special-case of this that I use personally: svn:externals that point to other paths (and other revisions) of the parent repo. I'm curious if people think that teaching git-svn to handle this special case is more or less difficult than handling the general case. -...

The thing is, almost all the core git people happen to be busy at the same time at this moment. Johannes has just moved, Shawn and I are deep in day-jobs to the neck, ... Don't worry, it eventually will come. -

I meant to add as well that this is absolutely NOT the thing that you want to be tracked. There are any number of times while using externals that I reorganised a directory only to have to change the svn:externals in the parent. That change is then tracked, so if you check out an earlier version not only do you not get a particular revision you also don't get the right URL, so subverion doesn't even fetch the current version. Gah! Andy -- Dr Andy Parkins, M Eng (hons), MIET andyp...

Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at> --- test-delta.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/test-delta.c b/test-delta.c index 16595ef..3d885ff 100644 --- a/test-delta.c +++ b/test-delta.c @@ -10,8 +10,9 @@ #include "git-compat-util.h" #include "delta.h" +#include "cache.h" -static const char usage[] = +static const char usage_str[] = "test-delta (-d|-p) <from_file> <data_file> <out_file>"; int...

Something like: $ git bisect run ! grep string my_file does not work right now, probably because '!' is a shell keyword. (This simple script shows the problem: $ echo "#"\!"/bin/sh" > ./simple_test.sh $ echo "echo \"running:\" \"\$@\"" >> ./simple_test.sh $ echo "\"\$@\"" >> ./simple_test.sh $ chmod +x ./simple_test.sh $ ./simple_test.sh ! grep foo bar.txt running: ! grep foo bar.txt ./simple_test.sh: line 3: !: command not found ) This patch tries to work around...

When the -v is passed, git-tag will exit after it is processed like it does with the -d and -l options. Additionally, missing code block caused wrong rendering of an option example. Signed-off-by: Jonas Fonseca <fonseca@diku.dk> --- Documentation/git-tag.txt | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt index 70235e8..4e3e027 100644 --- a/Documentation/git-tag.txt +++ b/Documentation/git-tag.txt @@ -9,9...

This by itself does not seem to do anything (no logic, no command line option parsing, nothing). Why is this a separate patch? -

Also an EXAMPLES section to Documentation/git-send-email.txt would be useful. -

In a previous version of this patchset I explained that I had turned on no_reuse_delta because I hadn't yet verified all the combinations in the reuse codepath(s). I guess I'll be reinspecting them sooner Sorry, you lost me. git is being bisected, or a project managed by git? My intent was that the pack splitting wouldn't be available until _all_ patches were applied (active). Bisecting git _within_ this patchset would still be useful -- it could be used to isolate where some of this new code brok...

What about keeping track of how many objects in nr_result that have been written already in the prior iteration of this do{} while loop and using that to set hdr_entries? This way if you are splitting into multiple packfiles the last packfile won't need to do a header/footer fixup. -- Shawn. -