Re: [PATCH v2 1/2] sparse-checkout: custom tab completion tests

> On Tue, Jan 4, 2022 at 11:26 AM Lessley Dennington
> <lessleydennington@gmail.com> wrote:
>>
>>
>>
>> On 12/31/21 4:20 PM, Junio C Hamano wrote:
>>> Elijah Newren <newren@gmail.com> writes:
>>>
>>>> Second, and this item is unrelated to your series but your comment
>>>> made me realize it....sparse-checkout unfortunately ignores prefix and
>>>> creates a bad .git/info/sparse-checkout file.  For example:
>>>> ...
>>>> I think the loss of the current working directory will be fixed by the
>>>> en/keep-cwd directory (currently in next and marked for merging to
>>>> master), but the fact that the wrong paths end up in the
>>>> sparse-checkout file is unfortunate.  It basically means that the
>>>> `set` and `add` subcommands of `sparse-checkout` can only be safely
>>>> run from the toplevel directory.
>>>
>>> You made it sound as if this is a fundamental limitation, but it
>>> sounds more like a bug that needs to be fixed (outside the
>>> completion series, of course) to me.
>>>
>> I can file a bug report if that's the correct way to proceed.
> 
> We don't really have a bug tracker.
> 
> We often just file an email, and add additional searchable strings
> (e.g. #leftoverbits, though that doesn't apply here), and then search
> via https://lore.kernel.org/git/.
> 
> There is 'git bugreport', but it just generates an email to send to
> the mailing list...but we already have the emails in this thread.
> 
> There is https://bugs.chromium.org/p/git/issues/list, which is used by
> a few folks, but I suspect I'm the only one who has looked at it that
> touches sparse-checkout related stuff.
> 
> There is https://github.com/git-for-windows/git/issues, but this isn't
> Windows specific.  (Sometimes they'll track stuff that isn't windows
> specific, but I've seen Dscho close out issues after being reported to
> this list.)
> 
> I've also kept private files with lists of things to work on.  Doesn't
> help anyone else track it.  (Which is why I'll sometimes use one of
> the two above trackers instead.)
> 
> ...not sure if that helps, but that's the basic state of our "bug tracking".