On 2023-11-02 at 08:53:36, Martin Ågren wrote: > On Thu, 2 Nov 2023 at 00:53, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > > > "brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: > > > > > From: Martin Ågren <martin.agren@xxxxxxxxx> > > > > > > `git merge-file` takes three positional arguments. Each of them is > > > documented as `<foo-file>`. In preparation for teaching this command to > > > alternatively take three object IDs, make these placeholders a bit more > > > > Minor nit. Don't we want to say "three blob object names"? Unless > > we plan to grow this feature into accepting three tree object names, > > that is. > > Hmm, yeah. Or just "three non-filename arguments". I do wonder: doesn't > this mean that the second patch could/should possibly move away from the > notion of "object ID"/`--object-id`? (That's not trying to shift any > blame from one patch to the other, that's my honest reaction.) Not specifying an option would make this ambiguous. What if I have a file named "e69de29bb2d1d6434b8b29ae775ad8c2e48c5391"? Is that the empty blob, or is it that file? Normally we have ways to disambiguate this, but those don't work here because of the positional arguments. > Ah, yes, I thought I recognized this. Quoting your response [1] to v2: > > > I briefly thought about suggesting --blob-id instead of --object-id > > simply because you'd never want to feed it trees and commits, but > > the error message from read_mmblob() the users would get mentions > > 'blob' to signal that non-blob objects are unwelcome, so the name of > > the optionwould be OK as-is. > > Maybe you having a similar reaction a second time makes this smell a bit > more? I think the name is fine. We don't typically use the phrase "blob ID" anywhere, but we do say "object ID". We'd need to say "--blob", but I'm not sure that's an improvement, and I fear it may be less understandable. -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
