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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 1/4/22 2:25 PM, Elijah Newren wrote:
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".

This is actually great context - thanks for providing! I'll go with the
email strategy for visibility and will base my format off [1].

[1]: https://lore.kernel.org/git/CABceR4bZmtC4rCwgxZ1BBYZP69VOUca1f_moJoP989vTUZWu9Q@xxxxxxxxxxxxxx/



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux