On Sun, Nov 26, 2023 at 5:39 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: [...] > >> Hmph, would an obvious alternative to (1) check against the HEAD (or > >> the index) to see if the prefix string matches an entity at the > >> current directory level, and then (2) to prefix the result of the > >> previous step with "/$(git rev-parse --show-prefix)" work? That is > >> something like this: > >> > >> $ cd t > >> $ git sparse-checkout add help<TAB> > >> -> > >> $ git sparse-checkout add /t/helper/ > > > > I thought bash-completion was only for completions, not for startings > > as well. Was I mistaken? > > To my mind, the completion is what I as an end user get when I type > <TAB> to help me formulate input that is acceptable by the command. > As I said, I consider it a bug (or UI mistake) in the a command if > it pretends to work inside a subdirecctory but complains when it is > given a path relative to the current directory, so I'd rather prefer > the approach to "fix" the underlying command, but if that is too > much work or cannot be done for whatever reason, the second best > would be to turn whatever we can do to help the end-user input into > a form that is accepted by the command without changing what the > input means. If it takes more than "appending at the end", that is > fine, at least by me as an end user. > > If you are saying "completion code can only append at the end > because we can only return strings to be appended, not the entire > strings, to the readline machinery, so mucking with the start of the > string is not doable", then sorry---I accept that what we cannot do > cannot be done, and in that case you are "not mistaken". This was what I thought; that bash completion didn't support this. > But from the existing use of COMPREPLY[], it didn't look that way > (it seems __gitcomp is equipped to take fixed prefix to all > candidates by passing it in $2 and used to complete names of > configuration variables in a section, but it seems to me that it can > be repurposed when prefixing "$(git rev-parse --show-prefix)" to a > given pathname relative to the $cwd). Ooh, that's really interesting; I had no idea it had this kind of flexibility. It does feel like we're abusing "bash completions" to be both "bash completions AND startings", but I agree that this is a case where it makes sense to do so. I changed patch 4 to implement this for non-cone mode, and submitted v3 with that change.
