From: Jeff King <peff@peff.net>
To: Johannes Sixt <j6t@kdbg.org>
Cc: git@vger.kernel.org, Michael Haggerty <mhagger@alum.mit.edu>
Subject: Re: [PATCH 1/5] t5312: test object deletion code paths in a corrupted repository
Date: Tue, 17 Mar 2015 14:55:50 -0400 [thread overview]
Message-ID: <20150317185550.GA14550@peff.net> (raw)
In-Reply-To: <5508739A.5030608@kdbg.org>
On Tue, Mar 17, 2015 at 07:34:02PM +0100, Johannes Sixt wrote:
> Am 17.03.2015 um 08:28 schrieb Jeff King:
> >+test_expect_success 'create history reachable only from a bogus-named ref' '
> >+ test_tick && git commit --allow-empty -m master &&
> >+ base=$(git rev-parse HEAD) &&
> >+ test_tick && git commit --allow-empty -m bogus &&
> >+ bogus=$(git rev-parse HEAD) &&
> >+ git cat-file commit $bogus >saved &&
> >+ echo $bogus >.git/refs/heads/bogus:name &&
>
> This causes headaches on Windows: It creates an empty file, named "bogus",
> with all the data diverted to the alternate data stream named "name".
> Needless to say that this...
Ah, yes. Windows. Our usual workaround would be to put it straight into
packed-refs, but in this case, the test really does need the badly named
ref in the file system. But...
> >+test_expect_success 'clean up bogus ref' '
> >+ rm .git/refs/heads/bogus:name
> >+'
>
> does not remove the file "bogus", but only the alternate data stream (if at
> all---I forgot to check). How about .git/refs/heads/bogus..nam.e?
Yes, that works. The colon is what originally brought my attention to
this case, but anything that fails git-check-ref-format is fine. I've
squashed this in:
diff --git a/t/t5312-prune-corruption.sh b/t/t5312-prune-corruption.sh
index 167031e..1001a69 100755
--- a/t/t5312-prune-corruption.sh
+++ b/t/t5312-prune-corruption.sh
@@ -21,7 +21,7 @@ test_expect_success 'create history reachable only from a bogus-named ref' '
test_tick && git commit --allow-empty -m bogus &&
bogus=$(git rev-parse HEAD) &&
git cat-file commit $bogus >saved &&
- echo $bogus >.git/refs/heads/bogus:name &&
+ echo $bogus >.git/refs/heads/bogus..name &&
git reset --hard HEAD^
'
@@ -47,7 +47,7 @@ test_expect_failure 'destructive repack keeps packed object' '
# subsequent tests will have different corruptions
test_expect_success 'clean up bogus ref' '
- rm .git/refs/heads/bogus:name
+ rm .git/refs/heads/bogus..name
'
test_expect_success 'create history with missing tip commit' '
I assumed the final "." in your example wasn't significant (it is not to
git), but let me know if I've run afoul of another weird restriction. :)
Thanks.
-Peff
next prev parent reply other threads:[~2015-03-17 18:55 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-17 7:27 [PATCH 0/5] not making corruption worse Jeff King
2015-03-17 7:28 ` [PATCH 1/5] t5312: test object deletion code paths in a corrupted repository Jeff King
2015-03-17 18:34 ` Johannes Sixt
2015-03-17 18:55 ` Jeff King [this message]
2015-03-18 20:42 ` Johannes Sixt
2015-03-19 20:04 ` Junio C Hamano
2015-03-19 20:51 ` Jeff King
2015-03-19 21:23 ` Junio C Hamano
2015-03-19 21:47 ` Jeff King
2015-03-19 21:49 ` Junio C Hamano
2015-03-19 21:52 ` Jeff King
2015-03-20 1:16 ` Eric Sunshine
2015-03-20 1:32 ` Jeff King
2015-03-20 1:37 ` Eric Sunshine
2015-03-20 2:08 ` test &&-chain lint (was: [PATCH 1/5] t5312: test object deletion code paths in a corrupted repository) Jeff King
2015-03-20 2:25 ` Jeff King
2015-03-20 5:10 ` Jeff King
2015-03-20 7:18 ` Eric Sunshine
2015-03-20 6:51 ` test &&-chain lint Junio C Hamano
2015-03-20 17:04 ` Junio C Hamano
2015-03-20 17:24 ` Jeff King
2015-03-20 17:34 ` Junio C Hamano
2015-03-20 17:59 ` Jeff King
2015-03-17 7:29 ` [PATCH 2/5] refs: introduce a "ref paranoia" flag Jeff King
2015-03-19 20:13 ` Junio C Hamano
2015-03-19 21:00 ` Jeff King
2015-03-19 21:31 ` Junio C Hamano
2015-03-19 21:51 ` Jeff King
2015-03-17 7:30 ` [PATCH 3/5] prune: turn on ref_paranoia flag Jeff King
2015-03-17 7:31 ` [PATCH 4/5] repack: turn on "ref paranoia" when doing a destructive repack Jeff King
2015-03-17 7:31 ` [PATCH 5/5] refs.c: drop curate_packed_refs Jeff King
2015-03-20 1:27 ` Eric Sunshine
2015-03-17 7:37 ` [PATCH 0/5] not making corruption worse Jeff King
2015-03-17 22:54 ` Junio C Hamano
2015-03-18 10:21 ` Jeff King
2015-03-20 18:42 ` [PATCH v2 " Jeff King
2015-03-20 18:43 ` [PATCH v2 1/5] t5312: test object deletion code paths in a corrupted repository Jeff King
2015-03-20 18:43 ` [PATCH v2 2/5] refs: introduce a "ref paranoia" flag Jeff King
2015-03-20 18:43 ` [PATCH v2 3/5] prune: turn on ref_paranoia flag Jeff King
2015-03-20 18:43 ` [PATCH v2 4/5] repack: turn on "ref paranoia" when doing a destructive repack Jeff King
2015-03-20 18:43 ` [PATCH v2 5/5] refs.c: drop curate_packed_refs Jeff King
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=20150317185550.GA14550@peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=j6t@kdbg.org \
--cc=mhagger@alum.mit.edu \
/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).