From: Justin Tobler Date: Mon, 15 Sep 2025 22:03:59 GMT Subject: Re: [PATCH 2/6] builtin/update-index: end ODB transaction when --verbose is specified Message-ID: In-Reply-To: <273dcsi6xmsdb356adxrlhh3renuimnl5wopfzkxxnryi5fmwd@xud2pvwdz57g> On 25/09/15 12:08PM, Justin Tobler wrote: > 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