On Fri, 12 Aug 2005, Petr Baudis wrote:
> Dear diary, on Fri, Aug 12, 2005 at 01:21:46AM CEST, I got a letter
> where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> > Petr Baudis <[EMAIL PROTECTED]> writes:
> >
> > > $ git-cat-file commit bf570303153902ec3d85570ed24515bcf8948848 | grep tree
> > > tree 41f10531f1799bbb31a1e0f7652363154ce96f45
> > > $ git-read-tree 41f10531f1799bbb31a1e0f7652363154ce96f45
> > > fatal: failed to unpack tree object
> > > 41f10531f1799bbb31a1e0f7652363154ce96f45
> >
> > > Kaboom. I think the issue might be that the reference dependency tree
> > > building is broken and it should've pulled the other pack as well.
> >
> > Last time I checked, git-http-pull did not utilize the pack
> > dependency information, which indeed is wrong. When it decides
> > to fetch a pack instead of an asked-for object, it should check
> > which commits the pack expects to have in your local repository
> > and add them to its list of things to slurp.
> >
> > A good news is that "git clone" as a whole works fine.
>
> Yes, but cg-clone doesn't - it naively depended on the core git tools
> actually, er.. working. ;-)
>
> This became a nightmare to me by now - on two machines I tried to pull
> to over HTTP, that failed miserably, and I got stuck until I applied
> Daniel's patch there (and cleaned up after previous git-http-pulls).
>
> So I have this packless git-pb repository and suspecting no evil, I pull
> from you (thankfully I have .git/objects/pack there from some historical
> pulls). I do a merge commit:
>
> packed
> ... J
> packed \
> > M
> /
> ... P
>
> Now I want to pull on another machine. That pulls M and then fails since
> I have no .git/objects/pack there, bummer. So I mkdir it, but get no
> further w/o Daniel's patch - for git-*-pull, J is missing and that's it.
> So I apply the patch, and get friendly
>
> error: Unable to determine requirements of type (null) for M
>
> and only after I delete M from the database, I finally succeed with
> git-http-pull. (That was with --repair.) That's not good since this
> might occur even naturally when the pull is interrupted.
Insufficient testing on my part; patch at the end.
> With git-ssh-pull, the situation is even more vexing - it refuses to
> fetch the packs for some reason yet unknown to me (I will debug it
> tomorrow).
git-ssh-pull doesn't deal in packs; it gets individual objects out of
packs, which git-ssh-push (on the remote side) should be extracting.
Perhaps you have a git-ssh-push on the remote side that's before I make
packs work (it used to need to have the files for objects it was sending).
At some point, I have to revisit getting git-ssh-* to generate exactly the
required pack and transfer that, but that's an efficiency issue, not a
correctness one, and shouldn't be relevant to the problem you're having.
---
[PATCH] Also parse objects we already have
In the case where we don't know from context what type an object is, but
we don't have to fetch it, we need to parse it to determine the type
before processing it.
Signed-off-by: Daniel Barkalow <[EMAIL PROTECTED]>
---
pull.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
b8c382e76da25f45ff86176a6a6affdd9a28d60b
diff --git a/pull.c b/pull.c
--- a/pull.c
+++ b/pull.c
@@ -127,6 +127,7 @@ static int process(unsigned char *sha1,
{
struct object *obj = lookup_object_type(sha1, type);
if (has_sha1_file(sha1)) {
+ parse_object(sha1);
/* We already have it, so we should scan it now. */
return process_object(obj);
}
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
