All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Steadmon <steadmon@google.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, gitster@pobox.com
Subject: Re: [PATCH v2] archive: initialize archivers earlier
Date: Mon, 22 Oct 2018 17:23:13 -0700	[thread overview]
Message-ID: <20181023002313.GF233961@google.com> (raw)
In-Reply-To: <20181023000616.GA27393@sigill.intra.peff.net>

On 2018.10.22 20:06, Jeff King wrote:
> On Mon, Oct 22, 2018 at 04:51:27PM -0700, Josh Steadmon wrote:
> 
> > > > +test_expect_success GZIP 'git archive with --output and --remote uses expected format' '
> > > > +	git archive --output=d5.tgz --remote=. HEAD &&
> > > > +	gzip -d -c < d5.tgz > d5.tar &&
> > > > +	test_cmp_bin b.tar d5.tar
> > > > +'
> > > 
> > > This nicely tests the more-interesting tgz case. But unfortunately it
> > > won't run on machines without the GZIP prerequisite. I'd think that
> > > would really be _most_ machines, but is it worth having a separate zip
> > > test to cover machines without gzip? I guess that just creates the
> > > opposite problem: not everybody has ZIP.
> > 
> > Added a test to compare the file lists from the .zip file to the
> > reference .tar file. I'm not sure if this is the best way to do things,
> > but it at least verifies that a .zip is produced. However, it's brittle
> > if the output of "zip -sf" changes. Let me know if you have a better
> > idea.
> 
> I wonder if we could do something more black-box. What we really care
> about here is not the exact output, but rather that "-o foo.zip"
> produces the same output as "--format zip". Could we do that without
> even relying on ZIP?
> 
> I think it should follow even for tgz, because we use "-n" for a
> repeatable output. But there we are relying on an external gzip just to
> _create_ the file, so we'd still need the GZIP prereq.
> 
> Hmm. Looks like we already have a similar test in t5003. So maybe just:
> 
> diff --git a/t/t5003-archive-zip.sh b/t/t5003-archive-zip.sh
> index 55c7870997..cf19f56924 100755
> --- a/t/t5003-archive-zip.sh
> +++ b/t/t5003-archive-zip.sh
> @@ -158,11 +158,16 @@ test_expect_success 'git archive --format=zip with --output' \
>      'git archive --format=zip --output=d2.zip HEAD &&
>      test_cmp_bin d.zip d2.zip'
>  
> -test_expect_success 'git archive with --output, inferring format' '
> +test_expect_success 'git archive with --output, inferring format (local)' '
>  	git archive --output=d3.zip HEAD &&
>  	test_cmp_bin d.zip d3.zip
>  '
>  
> +test_expect_success 'git archive with --output, ferring format (remote)' '
> +	git archive --remote=. --output=d4.zip HEAD &&
> +	test_cmp_bin d.zip d4.zip
> +'
> +
>  test_expect_success \
>      'git archive --format=zip with prefix' \
>      'git archive --format=zip --prefix=prefix/ HEAD >e.zip'
> 
> which I think exposes the bug and can run everywhere?

Makes sense, thanks!

  reply	other threads:[~2018-10-23  0:23 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-19 23:19 [PATCH 0/1] Fix format detection when archiving remotely steadmon
2018-10-19 23:19 ` [PATCH 1/1] archive: init archivers before determining format steadmon
2018-10-19 23:59   ` Jeff King
2018-10-22  3:24     ` Junio C Hamano
2018-10-22 21:47     ` Josh Steadmon
2018-10-22 22:30       ` Jeff King
2018-10-19 23:41 ` [PATCH 0/1] Fix format detection when archiving remotely Jeff King
2018-10-22 21:46   ` Josh Steadmon
2018-10-22 21:48 ` [PATCH v2] archive: initialize archivers earlier steadmon
2018-10-22 22:35   ` Jeff King
2018-10-22 23:51     ` Josh Steadmon
2018-10-23  0:06       ` Jeff King
2018-10-23  0:23         ` Josh Steadmon [this message]
2018-10-22 23:54   ` [PATCH v3] " steadmon
2018-10-23  0:20     ` [PATCH v4] " steadmon
2018-10-23  4:09     ` [PATCH v3] " Junio C Hamano
2018-10-25 20:29       ` Josh Steadmon
2018-10-25 20:32     ` [PATCH v5] " steadmon
2018-10-25 21:12       ` Jeff King
2018-10-26  1:14         ` 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=20181023002313.GF233961@google.com \
    --to=steadmon@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.