Re: [PATCH 2/6] builtin/update-index: end ODB transaction when --verbose is specified

From: Justin Tobler <jltobler@gmail.com>
Date: Sep 15, 2025, 22:03 UTC
Message-ID: <vtj334m5xckvve43nm332q5f5dfiy362wibygjh2ue5eu2g6hs@3o47ca5pha7u>
In-Reply-To: <273dcsi6xmsdb356adxrlhh3renuimnl5wopfzkxxnryi5fmwd@xud2pvwdz57g>

On 25/09/15 12:08PM, Justin Tobler wrote:

Show 10 quoted lines

> Looking into this a bit further, I originally thought this was so you
> could do something like:
> 
>   $ git update-index --remove foo --add bar
> 
> but this doesn't work because as soon as the --remove option is
> encountered, all subsequent file arguments are treated as a removed.
> This does mean though something like the following _does_ work:
> 
>   $ git update-index --add foo --remove bar

Whoops, in both of these examples I meant to use the --force-remove option instead of --remove. Once the --force-remove option is encountered, its codepath is used for all remaining filepaths. This leads to the behavior discrepancy between the above two examples.

> This is probably unintentional though and rather awkward. Due to the
> nature of argument parsing here, this interface has several other order
> related quirks like this.

Grepping through the codebase shows that we also have existing test cases that rely on the existing git-update-index(1) option order based behavior in both `t1001-read-tree-m-2way.sh` and `t1002-read-tree-m-u-2way.sh`. Still not sure if it was intentional, but it does seem to be used.

-Justin