From: Sergey Vlasov <vsu@altlinux.ru>
To: git@vger.kernel.org
Cc: Junio C Hamano <junkio@cox.net>
Subject: [PATCH 0/4] Recovery after interrupted HTTP(s) fetch
Date: Wed, 14 Sep 2005 16:42:06 +0400 [thread overview]
Message-ID: <20050914124206.GC24405@master.mivlgu.local> (raw)
[-- Attachment #1: Type: text/plain, Size: 1431 bytes --]
Hello!
The current implementation of git-http-fetch, git-local-fetch,
git-ssh-fetch has a problem: if a fetch was interrupted in the middle,
some objects in the local repository will be missing, and there is no
easy way to recover. If you just attempt to repeat the fetch, it will
notice that you already have the most recent commit object, and will
not fetch anything more - the repository will stay broken. Seems that
the only way to go forward is to prune the repository (which will
remove the fetched objects, because they are not referenced) and
repeat the fetch again from the beginning, but this is obviously
wasteful.
The problem is caused by the behavior of fetch.c:process_commit() - it
skips parent commits which already exist locally. This is a good
optimization if your repository is OK, but after an interrupted fetch
there will be some missing objects in the object tree; the only way to
find them is to scan the whole tree, so stopping at the existing
commits is wrong.
This set of patches adds the recovery mode to git-*-fetch and the
git-fetch script, which is enabled by the --recover option; in this
mode the program will walk through the whole object tree and try to
download any missing objects. Obviously, this could take some time,
but it is better than throwing away all already fetched objects after
an error in the middle of a long fetch operation.
--
Sergey Vlasov
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next reply other threads:[~2005-09-14 12:43 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-14 12:42 Sergey Vlasov [this message]
2005-09-14 12:42 ` [PATCH 1/4] Do not try to process objects more than once during fetch Sergey Vlasov
2005-09-14 12:45 ` [PATCH 2/4] git-*-fetch: Gracefully recover from retrieval failure Sergey Vlasov
2005-09-14 12:47 ` [PATCH 3/4] git-fetch: Add --recover option Sergey Vlasov
2005-09-14 12:48 ` [PATCH 4/4] Document git-fetch options Sergey Vlasov
2005-09-14 18:16 ` [PATCH 0/4] Recovery after interrupted HTTP(s) fetch Junio C Hamano
2005-09-14 20:27 ` Linus Torvalds
2005-09-14 20:48 ` Junio C Hamano
2005-09-14 20:55 ` Daniel Barkalow
2005-09-14 21:15 ` Linus Torvalds
2005-09-14 21:24 ` Daniel Barkalow
2005-09-14 21:53 ` Junio C Hamano
2005-09-15 10:35 ` Matthias Urlichs
2005-09-15 19:02 ` Daniel Barkalow
2005-09-15 19:31 ` Junio C Hamano
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=20050914124206.GC24405@master.mivlgu.local \
--to=vsu@altlinux.ru \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/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).