git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] Speed up bash completion loading

From
SZEDER Gábor <szeder@ira.uka.de>
Date
Nov 14, 2009, 14:43 UTC
Message-ID
<20091114144303.GA31540@neumann>
In-Reply-To
<20091114110141.GB1829@progeny.tock>
Hi,
On Sat, Nov 14, 2009 at 05:01:41AM -0600, Jonathan Nieder wrote:
Show 33 quoted lines
> Stephen Boyd wrote:
> 
> > I see a small problem, but it can be fixed in another patch. git
> > merge -s <TAB><TAB> the first time when you're not in a git
> > directory will make git merge -s <TAB><TAB> after never complete
> > correctly even in a git directory.
> 
> Not good.  I think the sanest thing to do is avoid caching the merge
> strategy list entirely.  Listing merge strategies takes about 100 ms
> here, which is short enough not to be annoying.
> 
> > I guess this become more serious
> > if git isn't in your path initially and you do git <TAB><TAB> and
> > then git becomes part of your path and you try again. Here you lose
> > porcelain completion. This is probably never going to happen though,
> > right?
> 
> Right, if this happened to me I would not be too surprised.  A similar
> problem occurs when someone installs a new git subcommand in the
> middle of a session.  Starting a new session fixes the completion, but
> should the completion script do something to help people before then?
> 
> It could provide a shell function with a slightly friendlier name than
> "__git_compute_porcelain_commands" for the user to invoke explicitly.
> 
> It could retry "git help -a" each time completion was needed if it
> gave no results last time (i.e. use "${__git_all_commands:=" instead
> of "${__git_all_commands=").  This would help with the missing git
> problem (which seems unusual), but not the missing git-svn.
> 
> Maybe it could detect signs of user frustration (repeated attempts to
> complete the same thing?) and add to the frustration by silently
> fixing the cache.
Why?  Don't get overly creative here, the command
  . /path/to/git-completion.bash

already does that, plus it fixes the merge strategy completion issue, and it's friendly enough for the users.

Best, Gábor

Previous: Jonathan NiederNext: Jonathan Nieder
Message 18 of 36 in “excerpts from tomorrow's "What's cooking" draft”
  1. Junio C HamanoNov 11, 2009
  2. Ben WaltonNov 11, 2009
  3. Johan HerlandNov 11, 2009
  4. Sverre RabbelierNov 11, 2009
  5. Daniel BarkalowNov 11, 2009
  6. Sverre RabbelierNov 15, 2009
  7. Daniel BarkalowNov 15, 2009
  8. ks/precompute-completionJonathan Nieder, Nov 11, 2009
  9. Stephen BoydNov 13, 2009
  10. Jonathan NiederNov 13, 2009
  11. Stephen BoydNov 13, 2009
  12. Speed up bash completion loadingJonathan Nieder, Nov 13, 2009
  13. Jonathan NiederNov 13, 2009
  14. Jonathan NiederNov 13, 2009
  15. Stephen BoydNov 13, 2009
  16. Jonathan NiederNov 14, 2009
  17. Jonathan NiederNov 14, 2009
  18. SZEDER GáborNov 14, 2009
  19. Jonathan NiederNov 14, 2009
  20. Stephen BoydNov 14, 2009
  21. Jonathan NiederNov 15, 2009
  22. Junio C HamanoNov 15, 2009
  23. Speed up bash completion loadingJonathan Nieder, Nov 15, 2009
  24. Shawn O. PearceNov 16, 2009
  25. Stephen BoydNov 16, 2009
  26. Speed up bash completion loadingJonathan Nieder, Nov 18, 2009
  27. Shawn O. PearceNov 18, 2009
  28. Nicolas SebrechtNov 11, 2009
  29. Nicolas PitreNov 11, 2009
  30. Petr BaudisNov 11, 2009
  31. Nicolas PitreNov 11, 2009
  32. Nicolas SebrechtNov 11, 2009
  33. Petr BaudisNov 11, 2009
  34. Nicolas PitreNov 11, 2009
  35. give priority to progress messagesNicolas Pitre, Nov 11, 2009
  36. Jakub NarebskiNov 11, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.