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

Re: [PATCH] Contributed bash completion support for core Git tools.

From
Shawn Pearce <spearce@spearce.org>
Date
Sep 18, 2006, 17:55 UTC
Message-ID
<20060918175509.GD31140@spearce.org>
In-Reply-To
<20060918083114.GQ20913@albany.tokkee.org>
Sebastian Harl <sh@tokkee.org> wrote:
Show 9 quoted lines
> Hi,
> 
> > This is a set of bash completion routines for many of the
> > popular core Git tools.  I wrote these routines from scratch
> > after reading the git-compl and git-compl-lib routines available
> > from the gitcompletion package at http://gitweb.hawaga.org.uk/
> > and found those to be lacking in functionality for some commands.
> 
> Did you talk to Ben Clifford (the maintainer of these scripts) before?

No. I found his scripts yesterday, played around with them for about 15 minutes and found them to be missing some features. In particular they don't actually list all branch names as they only list only those contained directly in refs/heads. This is certainly very annoying when your topic branch policy uses "sp/", "jh/", "lt/" as branch name prefixes. It also won't work with Linus' new packed ref format...

Ben's scripts also don't always complete tags at points where Git accepts a tag, nor can they complete through a path with git diff or git cat-file to yank a file out of another branch which doesn't exist in the current working directory. They also can't complete branch names in a remote repository when you are fetching or pushing.

So I set out to write my own, finished it in less than an hour, used it for 4 hours while doing some merging, and sent an email to put the script into contrib. :-)

> His scripts seem to be in pretty wide-spread use already, so it might
> make sense to join efforts and improve his scripts (and get them
> into git-core).

Agreed. There may be a few things my script is lacking but I think the one I sent yesterday is already more powerful than Ben's. But I'd like to see it be smarter about completion context and do even more. But right now I'm happy as it can complete my topic branch names and tag names.

I'd like to see core Git at least carry the completion for core Git. I know Ben has support for StGit and Cogito as well; two packages that my script doesn't support. In my humble opnion the completion scripts should migrate into the packages they support. I don't think its unreasonable to expect bash completion support to be part of a popular package which is heavily dependent on the shell for its user interface[*1*].

> > Consequently there may be some similarities but many differences.
> 
> Do you know of any (incompatible) differences?

None that I can think of. I believe that my script will complete anything Ben's does with the exception of a stray single character option here or there.

You can't load both into your shell at the same time as bash will only accept one completion function for any given command and both packages use the same function names to implement the completion logic.

[*1*] So long as there is someone to maintain it anyway.  :-)
-- 
Shawn.
Previous: Sebastian Harl
Message 11 of 11 in “Contributed bash completion support for core Git tools.”
  1. Contributed bash completion support for core Git tools.Shawn Pearce, Sep 18, 2006
  2. Junio C HamanoSep 18, 2006
  3. Shawn PearceSep 18, 2006
  4. Junio C HamanoSep 28, 2006
  5. Shawn PearceSep 28, 2006
  6. Johannes SchindelinSep 18, 2006
  7. Shawn PearceSep 18, 2006
  8. Junio C HamanoSep 18, 2006
  9. Shawn PearceSep 18, 2006
  10. Sebastian HarlSep 18, 2006
  11. Shawn PearceSep 18, 2006

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.