From: Junio C Hamano <junkio@cox.net>
To: Dirk Behme <dirk.behme@de.bosch.com>
Cc: git@vger.kernel.org
Subject: Re: 1dfcfbce2d643b7c7b56dc828f36ced9de2bf9f2
Date: Mon, 22 Aug 2005 18:07:18 -0700 [thread overview]
Message-ID: <7v64tx1mwp.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: 430988A7.60906@de.bosch.com
Dirk Behme <dirk.behme@de.bosch.com> writes:
>>>Seems to me that this breaks http update
Let's clarify one thing first. Did you mean "git rebuilt from
the sources obtained from that seemingly-odd commit, http update
does not work anymore", or did you mean "starting from the state
my repository happened to be in, attempting to pull from the
git.git repository did not work, and the master branch head of
git.git public repository was that commit"?
First we need to make sure your git binary from last week
wednesday or thursday is recent enough. I think you need at
least this commit:
Author: Daniel Barkalow <barkalow@iabervon.org>
Date: Thu Aug 11 23:17:55 2005 -0400
[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.
If your git binary turns out to be recent enough, then the state
of your repository is needed to diagnose this problem. What do
these command tell you in your git.git repository that cg-pull
from the public repository fails?
$ git fsck-cache | grep -v '^dangling '
$ git ls-remote --heads ./.
$ ls .git/objects/pack
[Note to people who are interested in what I plan to do with the
output from the above commands. If fsck-cache reports any
anomaly other than dangling objects, that means the repository
before pulling is corrupt and the problem is not in http-pull.
Otherwise, I can first make a clone of my git.git repository
while expanding all the packs, overwrite the head references to
what "git ls-remotes" reports for Dirk's repository, run "git
prune" to lose objects Dirk would not have, and then try
running git-http-pull myself.
What set of packs Dirk has (and does not have) is there for
sanity checking --- if he has packs that I do not have myself,
that means he packed his repository himself. Which is not an
illegal thing to do at all, and I do not think that would
affect the operation of http-pull, it would be a good thing to
know while digging deeper, hence the request for that
information. ]
prev parent reply other threads:[~2005-08-23 1:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-21 18:49 1dfcfbce2d643b7c7b56dc828f36ced9de2bf9f2 Junio C Hamano
2005-08-22 6:06 ` 1dfcfbce2d643b7c7b56dc828f36ced9de2bf9f2 Dirk Behme
2005-08-22 7:44 ` 1dfcfbce2d643b7c7b56dc828f36ced9de2bf9f2 Junio C Hamano
2005-08-22 8:11 ` 1dfcfbce2d643b7c7b56dc828f36ced9de2bf9f2 Dirk Behme
2005-08-23 1:07 ` Junio C Hamano [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7v64tx1mwp.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=dirk.behme@de.bosch.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).