# Removing NO_PARSEOPT from builtins turns up a completion problem in fast-import _A cleanup meant to make bash completion work for four builtins showed that fast-import only parses options after it reads input._ Section: Patches. Edition of 2026-10-26. Written by an AI editor from the thread "[Outreachy PATCH] git.c: drop NO_PARSEOPT from builtins that use parse-options" (18 messages): https://gitlist.dev/t/66649 Tanga Joris sent an Outreachy patch to drop the NO_PARSEOPT flag from builtins in git.c that already use parse-options. The flag leaves a command out of "git --list-cmds=parseopt", which bash completion uses to decide whether it can ask the command for its options with --git-completion-helper. The patch cites patch-id, diff-pairs and fast-import as converted commands still carrying the flag, and Tanga's reply also names var. René Scharfe asked whether the completion scripts would still work smoothly for fast-import. He noted that "git fast-import --git-completion-helper" prints its options only after it is fed a line of input, which he called odd. Tanga confirmed the problem. The __git() helper in the completion script does not redirect stdin, so the helper reads from the terminal and "git fast-import --" waits until the user presses return or ^D. Tanga attributed this to fast-import calling parse_options() only after it sees the first command in the stream, or EOF, because it reads the "feature" lines first. Tanga will send a v2 that still removes the flag from patch-id, diff-pairs and var, which return immediately, but keeps it on fast-import. A separate patch would teach fast-import to answer --git-completion-helper without waiting, and ultimately remove the flag. Junio C Hamano also replied about a dependency on Christian Couder's cc/early-scan-options topic. He said Christian cannot approve it and Tanga does not need his permission. Dependent topics usually rely on topics that are at least in 'next', and he suggested Tanga review the topic, since positive reviews are what move topics forward.