login
Search
I noticed while scanning #git log that it appears that pack-refs
was run in your public repo and some people cannot clone over
dumb protocols with older git.
commit 2986c02217f98809d8990e7679edf0f5d99f904d
Author: Junio C Hamano <junkio@cox.net>
Date: Wed Nov 22 22:24:09 2006 -0800
git-fetch: fix dumb protocol transport to fetch from pack-pruned ref
was the first revision that aligned dumb protocol clients with
pack-ref; unfortunately anything older will not find the ref
that was packed.
We do have a backward compatibility warning on this in v1.5.0
release notes draft, but I think we would make it more obvious.
Sigh...
-
Just to be on the safe side, let's not run pack-refs from git-gc without an explicit "[gc] packrefs = true" configuration. This default should be changed in the future when we can reasonably assume that everybody runs post v1.5.0-rc0 version of git, at which time people can still ask it not to run with the same configuration ("[gc] packrefs = false"). Signed-off-by: Junio C Hamano <junkio@cox.net> --- diff --git a/Documentation/config.txt b/Documentation/config.txt index 0129b1f..36b2c4f 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -321,6 +321,16 @@ format.headers:: Additional email headers to include in a patch to be submitted by mail. See gitlink:git-format-patch[1]. +gc.packrefs:: + `git gc` does not run `git pack-refs` by default + so that older dumb-transport clients can still fetch + from the repository. Setting this to `true` lets `git + gc` to run `git pack-refs`. Enable it only when you + know you do not have to support such clients. The + default will change to run `git pack-refs` in some + future, and setting this to `false` will continue to + prevent `git pack-refs` from being run from `git gc`. + gc.reflogexpire:: `git reflog expire` removes reflog entries older than this time; defaults to 90 days. diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt index e37758a..ca38c2e 100644 --- a/Documentation/git-gc.txt +++ b/Documentation/git-gc.txt @@ -62,9 +62,14 @@ The optional configuration variable 'gc.rerereunresolved' indicates how long records of conflicted merge you have not resolved are kept. This defaults to 15 days. +The optional configuration variable 'gc.packrefs' determines if +`git gc` runs `git-pack-refs`. Without the configuration, `git-pack-refs` +is not run by default to allow older dumb-transport clients +fetch from the repository, but this will change in the future. See Also -------- +gitlink:git-pack-refs[1] gitlink:git-prune[1] gitlink:git-reflog[1] ...
Hi, It seems to me that the reason are dumb transports, which are very likely to run only from bare repositories. How about checking for a bare repository explicitely, and only if it _is_ bare, check for gc.packrefs, too? Packed refs _do_ have a tremendous advantage (when you have a lot of tags, like many CVS switchers). Ciao, Dscho -
The way you have stated it, I think we will get a lot of "I set gc.packrefs, but it doesn't do anything!" complaints. I think a tri-state "yes/no/notbare" defaulting to "notbare" makes more sense. But maybe you meant the other way around in the first place. -Peff -
Hi, No, I meant it as you understood it. But your solution is evidently way more elegant. Ciao, Dscho -
The config variable gc.packrefs is tristate now: "true", "false" and "notbare", where "notbare" is the default. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> --- On Tue, 13 Feb 2007, Jeff King wrote: > I think a tri-state "yes/no/notbare" defaulting to "notbare" > makes more sense. This is on top of Junio's patch. Documentation/config.txt | 13 +++++++------ Documentation/git-gc.txt | 4 ++-- git-gc.sh | 14 +++++++++----- 3 files changed, 18 insertions(+), 13 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 36b2c4f..3865535 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -322,13 +322,14 @@ format.headers:: by mail. See gitlink:git-format-patch[1]. gc.packrefs:: - `git gc` does not run `git pack-refs` by default - so that older dumb-transport clients can still fetch + `git gc` does not run `git pack-refs` in a bare repository by + default so that older dumb-transport clients can still fetch from the repository. Setting this to `true` lets `git - gc` to run `git pack-refs`. Enable it only when you - know you do not have to support such clients. The - default will change to run `git pack-refs` in some - future, and setting this to `false` will continue to + gc` to run `git pack-refs`. Setting this to `false` tells + `git gc` never to run `git pack-refs`. The default setting is + `notbare`. Enable it only when you know you do not have to + support such clients. The default setting will change to `true` + at some stage, and setting this to `false` will continue to prevent `git pack-refs` from being run from `git gc`. gc.reflogexpire:: diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt index ca38c2e..910f12a 100644 --- a/Documentation/git-gc.txt +++ b/Documentation/git-gc.txt @@ -64,8 +64,8 @@ kept. This defaults to 15 days. The optional configuration variable 'gc.packrefs' determines if `git gc` runs ...
Stupid question. Suppose someone has run git pack-refs on a repository. What is the recommended way to reverse the process. Is the answer is to clone the repository and then throw away the original one? Is there another way to do it? - Ted -
Hi, The easiest way I found here was to do git-for-each-ref | while read sha1 tag name; do git update-ref -m "undo pack-ref" $name $sha1 done Beware: this is tested once, and copied from memory. Ciao, Dscho -
