On Fri, Mar 21, 2025 at 02:24:05PM -0400, Peijian Ju wrote: > > Thank you Peff. I like the idea "... it is not an error to ask for > %(objecttype), but you will just not get useful data for those > entries." > > So if we do remote-object-info with format "%(objectname) > %(objectsize) %(objecttype) %(objectsize:disk)", the response can be: > > 4346b22767c07e31d0f9b524fcb377972d957313 199 ??? ??? > > > Where ??? means the placeholder is not yet supported. In this way we > don't have to change the default format, and as new support for the > placeholders is added, ??? will be replaced by meaningful data. Yes, something like that. I don't know what the placeholder should be. In similar situations for the ref-filter printer, I think we use the empty string for unsupported cases. E.g.: git for-each-ref --format='%(refname) %(tagger)' will show the empty string for %(tagger) of non-tags. That lets you use conditionals like %(if) to switch behavior. The cat-file formatter doesn't use ref-filter now, but I think in the long run we'd want to unify them. So it probably makes sense to match its behavior. > About intermixing remote and local object requests, do you mean what > happens when remote-object-info is passed oids of objects that are > available locally instead of on a remote? If so, I have these > scenarios: No, I meant that --batch-command takes a single format string, but you can issue both local and remote requests to it. So for example: git cat-file --batch-command='%(objectname) %(objecttype) %(objectsize)' <<\EOF info 683c54c999c301c2cd6f715c411407c413b1d84e remote-object-info c9d3534de317f31915f37e9d9c0d52d4cf901482 EOF would show the local info for the first object, and remote info for the other. If you're only issuing remote-object-info commands, obviously it's dumb to include %(objecttype) which cannot be filled. But in the example above, it is possibly useful to get more data on the local objects, and a reduced set of data for the remote ones. > 1. An object is on remote but not on local. This is what > `remote-object-info` primarily focuses on: we retrieve info from > remote without downloading the object. > 2. An object is on remote as well as on local. I think > `remote-object-info` should still retrieve info from remote instead of > checking local data. After all, if the user knows the object is on > local, they can use the `info` command. If remote-object-info is used, > it means we are interested in the information stored on the remote. > 3. An object is not on remote, but only on local. I think > remote-object-info should fail in this case, since the remote doesn't > have the object. The info command should be used in this case. Yeah, agreed. remote-object-info should always predictably ask the remote. -Peff
