On Wed, 22 Feb 2006 10:17:58 -0800, Andrew Vasquez wrote:
> Commit:
>
> b5b16990f8b074bd0481ced047b8f8bf66eee6dc
> Prevent git-upload-pack segfault if object cannot be found
>
> is causing some really annoying noise being sent to stderr on some of
> my older non-packed repositories:
>
> $ git status
> # On branch refs/heads/b4
> unable to open object pack directory: .git/objects/pack: No such file or directory
> nothing to commit
Hmm... I can see that would be really annoying.
> > - if (!dir)
> > + if (!dir) {
> > + fprintf(stderr, "unable to open object pack directory: %s: %s\n", path, strerror(errno));
> > return;
> > + }
>
> Could we drop this fprintf to stderr?
In the case in which I hit the original bug, this message is necessary
to provide information about where the actual problem is. Here is what
that scenario looks like with the message:
$ mkdir original;
$ (cd original; git-init-db; touch foo; git add foo; git commit -m "original")
defaulting to local storage area
Committing initial tree 4d5fcadc293a348e88f777dc0920f11e7d71441c
$ git clone -l -s original clone
$ mv original moved
$ git clone clone again
unable to open object pack directory: /tmp/original/.git/objects/pack: No such file or directory
fatal: git-upload-pack: cannot find object 0153d496df669cbe5cecb665dbe6f95b20461917:
fatal: unexpected EOF
clone-pack from '/tmp/clone/.git' failed.
Here the "cannot find object" message doesn't point to the core
problem, but the "unable to open object pack directory" does contain
the "/tmp/original" path of interest.
One could be a bit more careful about not complaining if <objdir>
actually does exist, even if <objdir>/pack does not.
Or a workaround would be to just run git-init-db in old repositories
to create the pack directory:
$ rmdir .git/objects/pack/
$ git status
unable to open object pack directory: .git/objects/pack: No such file or directory
nothing to commit
$ git-init-db
defaulting to local storage area
$ git status
nothing to commit
-Carl
Attachment:
pgpzIrnyYwKq5.pgp
Description: PGP signature