Your understanding is correct. Throughout the pack-objects program, delta_size is always expressed in uncompressed number of bytes. The original description you quoted above does not even say "the size of the delta data (compressed)", so in that sense I do not think the original description is really an error; if the update makes the description Hmm. This is just terminology, but I think calling ref-delta and ofs-delta "type of object", is confusing. This "type" field is about ...

Do I need to cd into each submodule dir and fetch/rebase? git submodule update doesn't seem to do anything, though I would assume it's used to update the submodules... Pat --

Yes. Be careful of which branch your submodule is on; if "git submodule update" has done anything in the past, you might not be on a branch at all, in which case you have to create a local branch with your changes before you can safely rebase or push. Avery --

It is a bit confusing on first read, that "The packed archive format (.pack) is designed to be unpackable..." Signed-off-by: Peter Eriksen <s022018@student.dtu.dk> --- Documentation/git-pack-objects.txt | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt index eed0a94..3a1be08 100644 --- a/Documentation/git-pack-objects.txt +++ b/Documentation/git-pack-objects.txt @@ -22,8 ...

So that `git fetch origin tag` will try and fetch the branch named tag? Given that we treat "tag foo" as shorthand for refs/tags/foo:refs/ tags/foo it seems like it would be unexpected to treat "tag" as just a plain ref. I much prefer to die in this situation, let the user fix the refspec to mean exactly what they want (either by adding a tag name, or by using tag: if they really want a branch named tag). -Kevin -- Kevin ...

The current documentation does not mention the ofs_delta pack object type. This patch is also supposed to make the text a bit more readable, since it moves the object entry header description earlier. I fixes one error in these lines: If it is DELTA, then 20-byte base object name SHA1 (the size above is the size of the delta data that follows). The size given in the object header is actually the inflated size of the delta data that follows, since the call ...

Hello, I'm getting an error when I try to clone a git repo: $ git clone ~dab143/src/OVER-REL/SOURCE-GIT-TEST OVER-REL Initialized empty Git repository in /home/cfr100/OVER-REL/.git/ cpio: objects/pack/pack-80a0460fc07be5e0628b02549fdaa186b792d3f3.keep: Permission denied 888 blocks # cat pack-80a0460fc07be5e0628b02549fdaa186b792d3f3.keep fetch-pack 31620 on githost.arl.psu.edu Permission on the keep file are 600. Of course this looks like a stale lock of some sort. We are using git ...

Signed-off-by: Stephan Beyer <s-beyer@gmx.net> --- Hi, This is a `Janitor patch' to get involved ;-) See http://git.or.cz/gitwiki/Janitor It does not (at least, should not) change any functionality and it has been tested using some aliases. Regards, Stephan alias.c | 8 ++------ 1 files changed, 2 insertions(+), 6 deletions(-) diff --git a/alias.c b/alias.c index 116cac8..ac88d38 100644 --- a/alias.c +++ b/alias.c @@ -4,12 +4,8 @@ static const char *alias_key; static ...

Well, because alias_val is not a constant[1], changing static char *alias_val; to static const char *alias_val; is not an option. The only other way I see[2] atm is a brain-damaged: -- static int alias_lookup_cb(const char *k, const char *v) { if (!prefixcmp(k, "alias.") && !strcmp(k+6, alias_key)) { const char *tmp; int ret = git_config_string(&tmp, k, v); alias_val = xstrdup(tmp); /* actually, tmp should be free()'d. */ return ret; } return 0; } -- But instead ...

Hi, I found myself in a position to compile Git on Nexenta, and ran into the incredibly smart Makefile logic to pick "ginstall" when `uname -s` equals SunOS. Except that on GNU/*, it's install, not ginstall. Would not it be time to completely use automake? --

Signed-off-by: Christian Couder <chriscool@tuxfamily.org> --- po/fr.po | 78 ++++++++++++++++++++++++++----------------------------------- 1 files changed, 33 insertions(+), 45 deletions(-) Carefull, the encoding of this patch is probably broken. Please get it from the mob branch of git-gui-i18n.git instead. diff --git a/po/fr.po b/po/fr.po index d281938..89b6d51 100644 --- a/po/fr.po +++ b/po/fr.po @@ -9,7 +9,7 @@ msgstr "" "Project-Id-Version: fr\n" "Report-Msgid-Bugs-To: \n" ...

The last command there didn't get you the most efficiently packed repository possible. More recent versions of git-clone will prefer to hardlink all of the loose objects and packs from the source to the destination, so the clone can occur more quickly when they are on the same filesystem. Really what you want to do here is repack the cloned directory (cd git-samplesite && git repack -a -d -f) and maybe include some aggressive --depth and --window options (e.g. 100/100) if you have some CPU ...

Uhm, you forgot to use -s when doing the clone. That would have created real git branches instead of the directories... What you are counting is the size of the checked out, uncompressed files of _all_ branches and _all_ tags (and trunk). The repo size of basically what "du -sh .git" would give. Björn --

The svn folder (in the.git directory) was only about 4.2 MB. After running the repack (and then after that git gc as mentioned by another in this thread), it's still about 3.5 GB. git-samplesite (master)]$ du -hs ./* 2.1G ./branches 1.4G ./tags 66M ./trunk The site does have a lot of binary files (PDFs, photographs an such). I suppose we could leave all of the branches and tags in subversion and just move the trunk to git, but I was hoping to make a clean break from subversion. If ...

Yes, which means somebody needs to present a mergeable history rather sooner than later, and that somebody does not have to be me ;-) --

This reverts commit 6aa6f92fda47cc4ee5f599895e8a5a327fb6f9ab. It caused is_deleted() subroutine to output warnings when dealing with old, legacy gitweb blobdiff URLs without either 'hb' or 'hpb' parameters. This fixes http://bugs.debian.org/469083 Signed-off-by: Jakub Narebski <jnareb@gmail.com> And here it is... gitweb/gitweb.perl | 5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl index 1be75c6..1501ec8 100755 --- ...

No it does not. I have found what causes this bug. When adding is_deleted() subroutine I have forgot about old/legacy URL support[1], where gitweb doesn't have enough information to get raw diff info, and gitweb has to generate required info itself, i.e. the part in git_blobdiff(), around # old/legacy style URI if (!%diffinfo && # if new style URI failed defined $hash && defined $hash_parent) { # fake git-diff-tree raw output $diffinfo{'from_mode'} = $diffinfo{'to_mode'} = ...

Do you know whether this fixes http://bugs.debian.org/469083 too? I took a short look back then to fix it, but didn't manage it in a reasonable amount of time. Thanks, Gerrit. --

Not really directly relevant, but since no-one has replied: I daily copy several revisions onto (git push) and back from (git pull) to USB key (MS-DOS) on x86-Linux and it never takes more than a couple of seconds. (Repo is around 17MB packed, maybe 10-400 objects updated per push.) I know nothing about OS X, but the discrepancy between firewire and usb suggests some performance issue in usb handling. I don't know off the top of my head if packs on the receiveing end of a push are mmap()'d (to ...

Sadly Mac OS X does not like this accelerator in the menu. It drops the accelerator entirely and just shows nothing. I changed it to show "$M1T-=", but kept the bindings as -- Shawn. --

I'd favor, in the longer run: * --stat option to mean "show the diffstat between ORIG_HEAD and merge result" (i.e. current --summary); * perhaps a new configuration merge.stat to control the default for the above; * merge.log configuration to mean "add list of one-line log to the merge commit message" (i.e. current merge.summary); * perhaps a --log option to override the config default for each invocation. * deprecate --summary and merge.summary and remove them long ...

[missed the message because you dropped me from Cc:...] Ouch, that replaced your commit messages with the sha1 hashes... Should have been something like: git filter-branch --msg-filter 'sed "s,file:///....,http:///,"' -- --all Björn --

From a distribution point of view, configuration files for applications should reside in /etc/. On the other hand it's convenient for multiple instances of gitweb (e.g. virtual web servers on a single machine) to have a per-instance configuration file, just as gitweb currently supports through the file gitweb_config.perl next to the cgi. To support both at runtime, this commit introduces GITWEB_CONFIG_SYSTEM as a system-wide configuration file which will be used as a fallback if the config ...