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

Re: [PATCH/RFC 0/2] Automate updating git-completion.bash a bit

From
Duy Nguyen <pclouds@gmail.com>
Date
Jan 17, 2018, 09:34 UTC
Message-ID
<20180117093432.GA19189@ash>
In-Reply-To
<CACsJy8D3wRmP_o5iFJwWtODOJpj-r=JZsJ3P8XxWOCD8rJJrHA@mail.gmail.com>

Actually I forgot another option. What if we automate updating the script at "compile" time instead of calling git at run time? E.g. with something like below, a contributor could just run

    make update-completion

then add git-completion.bash changes to the same patch that introduces new options. If they forget, Junio could always run this near -rc0.

I know this output is a bit ugly. I probably could try to make the update work with wrapped __gitcomp lines to be friendlier to human eyes.

-- 8< --
diff --git a/Makefile b/Makefile
index 1a9b23b679..05eb7c8742 100644
--- a/Makefile
+++ b/Makefile
@@ -2834,3 +2834,5 @@ cover_db: coverage-report
 cover_db_html: cover_db
 	cover -report html -outputdir cover_db_html cover_db
 
+update-completion:
+	contrib/completion/update.sh contrib/completion/git-completion.bash ./git
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 3683c772c5..e8c224f486 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1585,21 +1585,7 @@ _git_grep ()
 
 	case "$cur" in
 	--*)
-		__gitcomp "
-			--cached
-			--text --ignore-case --word-regexp --invert-match
-			--full-name --line-number
-			--extended-regexp --basic-regexp --fixed-strings
-			--perl-regexp
-			--threads
-			--files-with-matches --name-only
-			--files-without-match
-			--max-depth
-			--count
-			--and --or --not --all-match
-			--break --heading --show-function --function-context
-			--untracked --no-index
-			"
+		__gitcomp_auto grep "--cached --text --ignore-case --word-regexp --invert-match --full-name --line-number --extended-regexp --basic-regexp --fixed-strings --perl-regexp --threads --files-with-matches --name-only --files-without-match --max-depth --count --and --or --not --all-match --break --heading --show-function --function-context --untracked --no-index"
 		return
 		;;
 	esac
diff --git a/contrib/completion/update.sh b/contrib/completion/update.sh
new file mode 100755
index 0000000000..99c4841152
--- /dev/null
+++ b/contrib/completion/update.sh
@@ -0,0 +1,8 @@
+#!/bin/sh
+
+file="$1"
+git="$2"
+
+grep __gitcomp_auto "$file" | while read a cmd b; do
+    sed -i "s/\\(.*$a $cmd \).*/\\1$("$git" $cmd --git-completion-helper)/" "$file"
+done
-- 8< --




On Wed, Jan 17, 2018 at 04:16:22PM +0700, Duy Nguyen wrote:
> On Wed, Jan 17, 2018 at 7:51 AM, SZEDER Gábor <szeder.dev@gmail.com> wrote:
> > On Tue, Jan 16, 2018 at 11:36 AM, Nguyễn Thái Ngọc Duy
> > <pclouds@gmail.com> wrote:
> >> I noticed --recurse-submodules was missing from git-grep complete
> >> list. Then I found a couple more should be on the list as well and
> >> many more in future may face the same faith. Perhaps this helps remedy
> >> this situation?
> >>
> >> This lets us extract certain information from git commands and feed it
> >> directly to git-completion.bash. Now long options by default will
> >> be complete-able (which also means it's the reviewer's and coder's
> >> responsibility to add "no complete" flag appropriately) but I think
> >> the number of new dangerous options will be much fewer than
> >> completeable ones.
> >>
> >> This is not really a new idea. Python has argcomplete that does more
> >> or less the same thing.
> >
> > This has come up before for Git as well, see:
> >
> >   https://public-inbox.org/git/1334140165-24958-1-git-send-email-bebarino@gmail.com/T/#u
> 
> Thanks! I did search the archive but couldn't find this one.
> 
> >
> > I see that your approach solves one of the shortcomings of those older
> > patches, namely it makes possible to omit dangerous options from
> > completion.  Great.
> >
> > I also see that you want to invoke git in a subshell every time the user
> > attempts to complete an --option.  Not so great, at least for Windows
> > users.  That older thread contains a few ideas about how to do it only
> > once by lazy-initializing a variable for each command to hold its
> > options.
> 
> Noted.
> 
> I see you also pointed out the problem with running commands like
> "git-status" without a repository. I'll try to address this too if
> possible (I'm thinking about making struct options[] available outside
> cmd_*(); then we could handle it more like "git --version" which
> always works)
> -- 
> Duy
Previous: Duy NguyenNext: SZEDER Gábor
Message 10 of 14 in “Automate updating git-completion.bash a bit”
  1. 0/2 Automate updating git-completion.bash a bitNguyễn Thái Ngọc Duy, Jan 16, 2018
  2. 1/2 parse-options: support --git-completion-helperNguyễn Thái Ngọc Duy, Jan 16, 2018
  3. Jacob KellerJan 16, 2018
  4. Duy NguyenJan 17, 2018
  5. Junio C HamanoJan 16, 2018
  6. Duy NguyenJan 17, 2018
  7. 2/2 git-completion: use --git-completion-helperNguyễn Thái Ngọc Duy, Jan 16, 2018
  8. SZEDER GáborJan 17, 2018
  9. Duy NguyenJan 17, 2018
  10. Duy NguyenJan 17, 2018
  11. SZEDER GáborJan 22, 2018
  12. Duy NguyenJan 23, 2018
  13. Duy NguyenApr 11, 2019
  14. Duy NguyenApr 11, 2019

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.