All of lore.kernel.org
 help / color / mirror / Atom feed
From: Taylor Blau <me@ttaylorr.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Taylor Blau <me@ttaylorr.com>,
	Matt Cooper via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org, derrickstolee@github.com,
	Matt Cooper <vtbassmatt@gmail.com>
Subject: Re: [PATCH 2/2] t5302: confirm that large packs mention limit
Date: Wed, 23 Feb 2022 18:41:21 -0500	[thread overview]
Message-ID: <YhbGIeksK7Df1QzS@nand.local> (raw)
In-Reply-To: <xmqqh78pp3k1.fsf@gitster.g>

On Wed, Feb 23, 2022 at 03:26:54PM -0800, Junio C Hamano wrote:
> > It's not a huge deal, and I'm sure we have plenty of examples of
> > slightly out-of-order commit trailers throughout our history. Personally
> > I don't consider it worth rerolling, but perhaps something to keep in
> > mind for future contributions :-).
>
> People need to understand that each such contributor robs maintainer
> bandwidth by not rerolling.

I figured you weren't going to tweak the trailers when applying, hence
"not a huge deal" in my comment above. But if it's going to cause you to
spend extra effort in order to pick these patches up, then I'm sure Matt
would be happy to reroll.

> >> +test_expect_success 'too-large packs report the breach' '
> >> +	pack=$(git pack-objects --all pack </dev/null) &&
> >> +	sz="$(test_file_size pack-$pack.pack)" &&
> >> +	test "$sz" -gt 20 &&
> >> +	test_must_fail git index-pack --max-input-size=20 pack-$pack.pack 2>err &&
> >> +	grep "maximum allowed size (20 bytes)" err
> >> +'
>
> This test looks OK to me.
>
> Shouldn't it be squashed into the previous patch?  After all, it is
> a test for the new behaviour introduced by the previous step, right?

Yeah. I mentioned in my response to Matt's cover letter that I figured
the two could be squashed together, and that there was no reason to keep
them separate.

(That was written under the assumption that he wasn't going to send a
reroll, in which case the advice was along the lines of "not a big deal
for this instance, but in the future...")

Thanks,
Taylor

  reply	other threads:[~2022-02-23 23:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-23 16:03 [PATCH 0/2] Specify the actual pack size limit which is breached Matt Cooper via GitGitGadget
2022-02-23 16:03 ` [PATCH 1/2] index-pack: clarify the breached limit Matt Cooper via GitGitGadget
2022-02-23 16:03 ` [PATCH 2/2] t5302: confirm that large packs mention limit Matt Cooper via GitGitGadget
2022-02-23 17:22   ` Taylor Blau
2022-02-23 23:26     ` Junio C Hamano
2022-02-23 23:41       ` Taylor Blau [this message]
2022-02-23 16:33 ` [PATCH 0/2] Specify the actual pack size limit which is breached Taylor Blau
2022-02-24  0:07 ` [PATCH v2] index-pack: clarify the breached limit Matt Cooper via GitGitGadget
2022-02-24  0:14   ` Ævar Arnfjörð Bjarmason

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=YhbGIeksK7Df1QzS@nand.local \
    --to=me@ttaylorr.com \
    --cc=derrickstolee@github.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=vtbassmatt@gmail.com \
    /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.