# [BUG] git checkout -p HEAD... 2 messages from 2020-09-29 to 2020-09-29. Participants: Denton Liu, Junio C Hamano. Thread: https://gitlist.dev/t/54321 ## Denton Liu, 2020-09-29 06:18 Subject: [BUG] git checkout -p HEAD... Message-ID: <20200929061830.GA40759@generichostname> URL: https://gitlist.dev/e/20200929061830.GA40759%40generichostname ``` Hi all, git checkout -p ... is broken: $ git checkout HEAD... -p usage: git diff-index [-m] [--cached] [] [...] common diff options: -z output diff-raw with lines terminated with NUL. -p output patch format. -u synonym for -p. --patch-with-raw output both a patch and the diff-raw format. --stat show diffstat instead of patch. --numstat show numeric diffstat instead of patch. --patch-with-stat output a patch and prepend its diffstat. --name-only show only names of changed files. --name-status show names and status of changed files. --full-index show full object name on index lines. --abbrev= abbreviate object names in diff-tree header and diff-raw. -R swap input file pairs. -B detect complete rewrites. -M detect renames. -C detect copies. --find-copies-harder try unchanged files as candidate for copy detection. -l limit rename attempts up to paths. -O reorder diffs according to the . -S find filepair whose only one side contains the string. --pickaxe-all show all files diff when -S is used and hit is found. -a --text treat all files as text. Cannot close git diff-index --cached --numstat --summary HEAD... -- () at /home/denton/.local/libexec/git-core/git-add--interactive line 183. The issue is simple: `HEAD...` is passed literally to `git diff-index` which does not know how to handle it. The fix is simple: figure out the OID and pass that instead. One thing I'm not quite sure about is that in the documentation, the restore-related checkout options accept and it's an implementation detail that the `...` form happens to work in the non-patch case. In fact, `git restore --source=HEAD...` works too (unless -p is given as well). So I lean on the side of fully supporting the `...` form for `git restore/checkout`. However, I understand if someone wishes to suggest "that was never valid to begin with; we should prohibit `...` from being used with restore-modes`. Any opposition to fully supporting the `...` form? Thanks, Denton ``` ## Junio C Hamano, 2020-09-29 16:02 Subject: Re: [BUG] git checkout -p HEAD... Message-ID: URL: https://gitlist.dev/e/xmqqlfgsinb7.fsf%40gitster.c.googlers.com In-Reply-To: <20200929061830.GA40759@generichostname> ``` Denton Liu writes: > So I lean on the side of fully supporting the `...` form for `git > restore/checkout`. However, I understand if someone wishes to suggest > "that was never valid to begin with; we should prohibit `...` from > being used with restore-modes`. > > Any opposition to fully supporting the `...` form? Not from me. The "-p" feature of various commands were bolted on as a mere afterthought and in a rather hacky way. I am not surprised if quality of their implementation differs from that of the primary codepaths. It did not help that they are implemented by diverting the control early to the "add--interactive" machinery from the primary control flow, and it may be a large, if not primary, source of differences in how command line options are handled by the "-p" codepath and the primary codepath in these commands. Making "-p" behave more like the primary modes of operation in these commands would be a welcome move, I would think. I hope that it got much easier to access the "add--interactive" machinery from C these days; probably it is a good time to make that move. Thanks. ```