Re: [PATCH v5 6/6] cat-file: add remote-object-info to batch-command
- From
Calvin Wan <calvinwan@google.com>
- Date
- Aug 8, 2022, 18:37 UTC
- Message-ID
- <CAFySSZAKibH3dcHLFz=1csKwfa3-Ebkou_-soQS3h_+ewoZfUw@mail.gmail.com>
- In-Reply-To
- <xmqq1qu37pbf.fsf@gitster.g>
Show 9 quoted lines
> > While `info` takes object ids one at a time, this creates overhead when > > making requests to a server so `remote-object-info` instead can take > > multiple object ids at once. > > I am not sure if the above is desirable---doesn't it make the > protocol (i.e. the requests the invoker of "cat-file" needs to > prepare) unnecessarily complex? If we have "buffered" mode, the > implementation can collect and batch requests and talk with the > other side in a single communication with the other end, no?
I'm a little bit confused as to what you are suggesting here, in terms of how a user would want to call this command. Are you saying this functionality should only work in "buffered" mode? Or are you saying that `remote-object-info` should only take one object id at a time, and in buffer mode, those requests are batched together?
Show 12 quoted lines
> > > In --buffer mode, this changes to: > > > > - Receive and parse input from user > > - Store respective function attached to command in a queue > > - After flush, loop through commands in queue > > - Call respective function attached to command > > - Set batch mode state, get object info, print object info > > So, the existing buffered mode is poorly designed, in other words. > Isn't this something we can fix for performance without affecting > the existing callers?
Much of the existing cat-file code seems to be designed around taking in one object/command at a time, and --buffer can be thought of as a wrapper around that preexisting code that simply stores a queue of commands rather than running them immediately. I think the existing buffered mode is well designed -- this part of the commit message is to explain why at some point I need to preprocess what is in the buffer