public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
From: David Disseldorp <ddiss@suse.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Teng Long <dyroneteng@gmail.com>
Subject: Re: [PATCH 1/2] t3301-notes: check editor isn't invoked for empty notes add
Date: Fri, 26 Jul 2024 01:10:04 +0200	[thread overview]
Message-ID: <20240726011004.6bde3938.ddiss@suse.de> (raw)
In-Reply-To: <xmqqle1pigbk.fsf@gitster.g>

On Thu, 25 Jul 2024 09:31:27 -0700, Junio C Hamano wrote:

> David Disseldorp <ddiss@suse.de> writes:
> 
> > 90bc19b3ae ("notes.c: introduce '--separator=<paragraph-break>' option")
> > changed note_data.given logic such that it's no longer set if a zero
> > length file or blob object is provided.
> >
> > Add a test for this regression by checking whether GIT_EDITOR is
> > invoked.
> >
> > Signed-off-by: David Disseldorp <ddiss@suse.de>
> > ---
> >  t/t3301-notes.sh | 5 +++++
> >  1 file changed, 5 insertions(+)  
> 
> Having this test separate from 2/2 breaks bisectability.  For a
> small test like this, it is often a lot more preferrable to squash
> it into the patch that updates the behaviour.  It is easy to apply
> the whole thing, and when the reviewer/tester is curious, it is easy
> to tentatively "revert" only the behaviour changes out of the
> working tree to see how the original code behaved against the test
> to verify the alleged breakages were indeed there in the original.

Understood. In that case I'll squash both patches together in the next
version.

> > diff --git a/t/t3301-notes.sh b/t/t3301-notes.sh
> > index 536bd11ff4..c0dbacc161 100755
> > --- a/t/t3301-notes.sh
> > +++ b/t/t3301-notes.sh
> > @@ -1557,4 +1557,9 @@ test_expect_success 'empty notes are displayed by git log' '
> >  	test_cmp expect actual
> >  '
> >  
> > +test_expect_success 'empty notes do not invoke the editor' '
> > +	test_commit 18th &&
> > +	GIT_EDITOR="false" git notes add -C "$empty_blob" --allow-empty
> > +'  
> 
> Clever.  By setting the editor to something that always fails, we
> will notice if the command invoked it, when we do not expect the
> editor to be used.
> 
> Not questioning the usefulness of this fix, and not suggesting to
> remove the "--allow-empty" support out of the "git notes" command,
> but out of curiosity, what are these empty notes used for?

icyci (https://github.com/ddiss/icyci) attaches test-suite stderr and
stdout notes following test completion. There's no real value in
attaching empty e.g. stderr notes, but tests can also provide their own
arbitrary notes files and may wish to use (empty) note existence as a
flag in results reporting.

  reply	other threads:[~2024-07-25 23:10 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-25 14:41 [PATCH 0/2] notes: fix editor invocation regression David Disseldorp
2024-07-25 14:41 ` [PATCH 1/2] t3301-notes: check editor isn't invoked for empty notes add David Disseldorp
2024-07-25 15:52   ` Kristoffer Haugsbakk
2024-07-25 16:03     ` David Disseldorp
2024-07-25 17:10     ` Junio C Hamano
2024-07-25 16:31   ` Junio C Hamano
2024-07-25 23:10     ` David Disseldorp [this message]
2024-07-25 14:41 ` [PATCH 2/2] notes: revert note_data.given behavior with " David Disseldorp
2024-07-25 17:09   ` Junio C Hamano
2024-07-25 17:22     ` Kristoffer Haugsbakk
2024-07-25 23:26     ` David Disseldorp

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=20240726011004.6bde3938.ddiss@suse.de \
    --to=ddiss@suse.de \
    --cc=dyroneteng@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox