On Thu, Dec 5, 2024 at 10:52 AM Patrick Steinhardt <ps@xxxxxx> wrote: > > On Tue, Dec 03, 2024 at 02:23:01PM -0500, Peijian Ju wrote: > > No, this isn’t stale. As I mentioned in my response to Junio in > > https://lore.kernel.org/git/CAN2LT1Cmsw3RB1kbRBvoeLs8WaQeZWqrG96EQfMkMe_jdKaO4g@xxxxxxxxxxxxxx/, > > adding type support is planned for the next patch series. Based on the > > documentation at https://git-scm.com/docs/protocol-v2#_object_info, it > > seems type isn’t yet supported on the server side either. My plan is > > to implement the logic for both server and client in the next series. > > > > Unless the reviewers feel strongly that this must be included now, I’d > > prefer to stick to the original plan. > > The problem is that you cannot introduce a different format first and > then change it in a subsequent patch series because that would be a > backwards-incompatible change. So if the follow-up patch series would > implement that you cannot revert back to the default format, and > consequently the behaviour would now be inconsistent with the non-remote > case without a good reason. The doc added with this patch clearly says that the default format is very likely to change in the future and that users should not rely on it. Also there are very simple ways for users (who are likely to be very advanced users) to use a custom format instead of the default format. If we always reject any backward-incompatible change, even on features we have clearly marked as experimental or temporary, then it means there is no point in marking features as experimental or temporary in the docs, and it will make developing new features more difficult as we will likely have to spend a lot of time to get it right the first time instead developing them organically. As we will likely fail in some cases to get it right the first time, it will mean more things we will have to redo in other ways and more things we will have to deprecate and eventually remove, which will be bad for backward compatibility anyway.
