Overall, I agree that this option does not belong in fetch. I wouldn't say I chose to put it there for the sake of implementation convenience, but because "it does what fetch is supposed to do minus the object itself". This logic no longer makes any sense to me, and I regret not seeing the problems with it as I was coming up with workarounds. > I think that "Object 'size' is currently the only one the server > knows to emit", combined with the lack of any client side support so > far, means that it is not too late to rework the object-info thing > and possibly reuse more from "cat-file --batch-check". I talked this over with Jonathan Tan and we came to the conclusion that this is the next option I should look into, rather than separating it out into its own command. Thank you for the review Junio! I appreciate how straightforward all of your comments are. On Tue, Mar 29, 2022 at 5:49 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Junio C Hamano <gitster@xxxxxxxxx> writes: > > > Shouldn't we be making the part that we truly need to reuse into a > > separate API out of fetch-pack and either (1) allow new commands be > > easily written reusing the code to create "git remote-object-info" > > and "git remote-blame", or (2) come up with a single "do things on > > remote" command with various subcommands, i.e. "git over-there > > object-info" and "git over-there blame"? > > For completeness, we could also make the "git archive" the gold > standard. If we want "git blame" that is mostly executed on the > remote site, we could teach "git blame --remote <there>", which may > be where a user, who does not know nor care about how things are > implemented, would expect to find the feature. Is "object-info" in > principle like executing "cat-file --batch-check" remotely? > > I think that "Object 'size' is currently the only one the server > knows to emit", combined with the lack of any client side support so > far, means that it is not too late to rework the object-info thing > and possibly reuse more from "cat-file --batch-check". > > If we can create a system where running things locally and remotely > are comparable in feature, that would be great, but I do not think > that is a realistic goal to aim for. > > Thoughts? > > >
