From: "jonsmirl@gmail.com" <jonsmirl@gmail.com>
To: weigelt@metux.de, Git Mailing List <git@vger.kernel.org>
Subject: Re: Recovering from a bad object
Date: Sun, 18 Sep 2011 15:48:55 -0400 [thread overview]
Message-ID: <CAKON4OzCYEQzKXwsNE59a-SOCHp=xibwk9oPmHs3_hMHCLaybg@mail.gmail.com> (raw)
In-Reply-To: <20110918193116.GB6334@nibiru.local>
On Sun, Sep 18, 2011 at 3:31 PM, Enrico Weigelt <weigelt@metux.de> wrote:
> * Junio C Hamano <gitster@pobox.com> wrote:
>
>> > The object is likely at kernel.org.
>> > Can git go fetch it somehow?
>>
>> The protocol is designed specifically to disallow "I guessed that the
>> trade secret is contained within an object whose object name is this,
>> please feed me that object" kind of requests, so in general no.
>
> Maybe the local side (in some special repair mode) could check if
> some of the remote refs (and their referenced graphs) are broken
> and refetch them completely. If the remote side(s) got the objects
> you're missing (visibile to you), you'll be done after that.
>
> For example:
>
> A local branch "foo" is based on origin/master, somewhere in the
> line behind origin/master some objects are broken:
>
> It would find out that origin/master points to broken/missing objects
> and refetch it completely afresh (same as it would if they had never
> been fetched yet).
>
That's describes the lines I was thinking along.
>
> Perhaps it's not that hard to implement: just requires a special
> git-fetch operation mode that ignores locally existing objects,
> and a few lines of shell code that simply fetches the whole remote
> to some temporary namespaces (and drop that when done). Ends up in
> the same traffic as a fresh clone, but at least runs automatically.
>
>
> cu
> --
> ----------------------------------------------------------------------
> Enrico Weigelt, metux IT service -- http://www.metux.de/
>
> phone: +49 36207 519931 email: weigelt@metux.de
> mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
> ----------------------------------------------------------------------
> Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
> ----------------------------------------------------------------------
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Jon Smirl
jonsmirl@gmail.com
prev parent reply other threads:[~2011-09-18 19:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-21 23:03 Recovering from a bad object jonsmirl
2011-05-22 20:42 ` Junio C Hamano
2011-05-22 22:31 ` jonsmirl
2011-05-22 22:47 ` jonsmirl
2011-05-23 2:09 ` Junio C Hamano
2011-09-18 19:31 ` Enrico Weigelt
2011-09-18 19:48 ` jonsmirl [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='CAKON4OzCYEQzKXwsNE59a-SOCHp=xibwk9oPmHs3_hMHCLaybg@mail.gmail.com' \
--to=jonsmirl@gmail.com \
--cc=git@vger.kernel.org \
--cc=weigelt@metux.de \
/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).