git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 0/4] Recovery after interrupted HTTP(s) fetch

From
Junio C Hamano <junkio@cox.net>
Date
Sep 15, 2005, 19:31 UTC
Message-ID
<7vu0gmyvoz.fsf@assigned-by-dhcp.cox.net>
In-Reply-To
<pan.2005.09.15.10.34.59.363606@smurf.noris.de>
Matthias Urlichs <smurf@smurf.noris.de> writes:
Show 7 quoted lines
> Personally I'd rather combine the two. The point being, broken
> repositories do happen -- for instance, when the file system is
> inconsistent after a crash, or when the referent of an info/alternates
> directory vanishes. :-/
>
> I'd rather have a simple repair flag than do a "download everything again
> and then throw most of it away" job when something like that happens.

If you are talking about disaster recovery, wouldn't you rather clone the remote into a clean repository, and fetch what are salvageable from the potentially corrupt old repository into this clean repository you know is OK? I think that would suggest that you do not need another "download everything again" added to git-http-fetch. You can already run git-clone from the remote to "download everything again", and then git-fetch from the repository being salvaged.

Previous: Daniel Barkalow
Message 15 of 15 in “Recovery after interrupted HTTP(s) fetch”
  1. 0/4 Recovery after interrupted HTTP(s) fetchSergey Vlasov, Sep 14, 2005
  2. 1/4 Do not try to process objects more than once during fetchSergey Vlasov, Sep 14, 2005
  3. 2/4 git-*-fetch: Gracefully recover from retrieval failureSergey Vlasov, Sep 14, 2005
  4. 3/4 git-fetch: Add --recover optionSergey Vlasov, Sep 14, 2005
  5. 4/4 Document git-fetch optionsSergey Vlasov, Sep 14, 2005
  6. Junio C HamanoSep 14, 2005
  7. Linus TorvaldsSep 14, 2005
  8. Junio C HamanoSep 14, 2005
  9. Daniel BarkalowSep 14, 2005
  10. Linus TorvaldsSep 14, 2005
  11. Daniel BarkalowSep 14, 2005
  12. Junio C HamanoSep 14, 2005
  13. Matthias UrlichsSep 15, 2005
  14. Daniel BarkalowSep 15, 2005
  15. Junio C HamanoSep 15, 2005

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.