Thread (15 messages) 15 messages, 3 authors, 2021-09-22

Re: Memory leak with sparse-checkout

flat view

From: Derrick Stolee <hidden>
Date: 2021-09-21 12:55:06

On 9/20/2021 5:20 PM, Taylor Blau wrote:
On Mon, Sep 20, 2021 at 04:56:47PM -0400, Derrick Stolee wrote:
quoted
quoted
quoted
I double-checked this to see how to fix this, and the 'list' subcommand
already notices that the patterns are not in cone mode and reverts its
behavior to writing all of the sparse-checkout file to stdout. It also
writes warnings over stderr before that.

There might not be anything pressing to do here.
Hmm. I think we'd probably want the same behavior for init and any other
commands which could potentially overwrite the contents of the
sparse-checkout file.
Could you elaborate on what you mean by "the same behavior"?

Do you mean that "git sparse-checkout add X" should act as if cone mode
is not enabled if the existing patterns are not cone-mode patterns?

What exactly do you mean about "init" changing behavior here?
No, I was referring to your suggestion from [1] to add a warning from
"git sparse-checkout init --cone" when there are existing patterns which
are not in cone-mode.
This warning is part of the sparse-checkout pattern parsing logic, so
it happens whenever the patterns are loaded, including the "list"
subcommand (among other commands, not just the sparse-checkout builtin).
quoted
quoted
Those may already call list routines internally, in which case I agree
that this is already taken care of. But if not, then I think we should
match list's behavior in the new locations, too.
"list" interprets the 'struct pattern_list' in two different ways,
depending on the use_cone_patterns member. They are static methods in
the builtin code, not used by anything else.
Ah, bummer. I was hoping that they'd be used internally by init so that
it would automatically emit a warning in the case where a user's
existing patterns are not in cone mode.

Apologies for any confusion.
Thanks for clearing it up!

-Stolee
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help