On Tue, Jan 4, 2022 at 11:26 AM Lessley Dennington <lessleydennington@xxxxxxxxx> wrote: > > > > On 12/31/21 4:20 PM, Junio C Hamano wrote: > > Elijah Newren <newren@xxxxxxxxx> 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".
