From: Junio C Hamano <gitster@pobox.com>
To: "René Scharfe" <l.s.r@web.de>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"Phillip Wood" <phillip.wood@dunelm.org.uk>,
git@vger.kernel.org, "Daniel Li" <dan@danielyli.com>
Subject: Re: [PATCH] 2.36 fast-export regression fix
Date: Sat, 30 Apr 2022 13:50:07 -0700 [thread overview]
Message-ID: <xmqq35hu8feo.fsf@gitster.g> (raw)
In-Reply-To: <2c988c7b-0efe-4222-4a43-8124fe1a9da6@web.de> (=?utf-8?Q?=22R?= =?utf-8?Q?en=C3=A9?= Scharfe"'s message of "Sat, 30 Apr 2022 16:31:43 +0200")
René Scharfe <l.s.r@web.de> writes:
> e900d494dc (diff: add an API for deferred freeing, 2021-02-11) added a
> way to allow reusing diffopts: the no_free bit. 244c27242f (diff.[ch]:
> have diff_free() call clear_pathspec(opts.pathspec), 2022-02-16) made
> that mechanism mandatory.
>
> git fast-export doesn't set no_free, so path limiting stopped working
> after the first commit. Set the flag and add a basic test to make sure
> only changes to the specified files are exported.
>
> Signed-off-by: René Scharfe <l.s.r@web.de>
> ---
Both format-patch fix and this one look good to me.
We have UNLEAK() in format-patch so that the fix will not result in
additional false positives from the leak checker. But this one, we
didn't have UNLEAK() so this may start tickling the leak checker
again. We may need to add UNLEAK() at some point.
Stopping a leak checker from complaining about a known singleton
leak that is at the top-level (i.e. does not become bigger with the
data) by spending extra cycles is pointless, compared to using
UNLEAK() to do the same, and it is doubly misguided if it breaks the
behaviour X-<.
Will queue both, thanks.
prev parent reply other threads:[~2022-04-30 20:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-30 2:22 Bug: `git show` honors path filters only for the first commit Daniel Li
2022-04-30 4:59 ` Junio C Hamano
2022-04-30 5:29 ` [PATCH] 2.36 show regression fix Junio C Hamano
2022-04-30 10:32 ` [PATCH] 2.36 format-patch " René Scharfe
2022-04-30 16:32 ` Carlo Marcelo Arenas Belón
2022-05-01 9:35 ` René Scharfe
2022-05-20 15:23 ` the state of diff_free() and release_revisions() (was: [PATCH] 2.36 format-patch regression fix) Ævar Arnfjörð Bjarmason
2022-05-20 17:23 ` the state of diff_free() and release_revisions() Junio C Hamano
2022-04-30 14:31 ` [PATCH] 2.36 fast-export regression fix René Scharfe
2022-04-30 20:50 ` Junio C Hamano [this message]
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=xmqq35hu8feo.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=avarab@gmail.com \
--cc=dan@danielyli.com \
--cc=git@vger.kernel.org \
--cc=l.s.r@web.de \
--cc=phillip.wood@dunelm.org.uk \
/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).