Drop git::Protocol::V1 support once V2 is the default in upstream git

[Byron]

Supporting it adds quite some complication to our codebase, namely:

• peek-line support in packet-line crate is only needed for V1, and adds a lot of tests and complication to deal with it properly. Refactoring is harder than it should due to the nature of the 'self-borrowing' of lines, which is also the reason the packetline Provider is not an iterator.
• all V1 logic/special cases in transport layer
• all V1 logic/special cases in protocol layer

[joshtriplett]

Dropping support for generating the V2 format (e.g. on the server end) seems fine. However, it'd be nice to be able to connect to older servers to pull and push.

[Byron]

Dropping support for generating the V2 format[…]

I assume V1 is meant, otherwise I would need more explanation.

However, it'd be nice to be able to connect to older servers to pull and push.

Personally I would be surprised to see any of these outside of personal installations, and would argue that someone who is years behind git-stable would be hesitant to use a new git implementation in the first place.

Code maintenance is my primary concern which would greatly benefit from not having that cruft around. I believe I would think differently if V1 wouldn't be such accidental 'mess' to begin with, but seeing both implementation next to each other, V1 feels like a third wheel.

Both opinions are perfectly valid, and the value question might be one to answer another time. This could be interesting as this could mean that gitoxide will only implement the latest stable version of some protocol, while ignoring the past or even dropping support for it during refactoring. (This is already done in one instance by choosing to never support the 'dumb' http protocol.)

[joshtriplett]

@Byron Yes, I meant "dropping support for generating anything but the V2 format".

I definitely understand not wanting to deal with V1. My concern would be trying to clone random repositories from around the Internet. I'm not sure how widespread support for the V2 format is. If basically everyone had upgraded, and git itself considers deprecating the V1 format with a message, dropping it from gitoxide makes sense. If some servers people want to clone from still only support V1, it'd be painful if gitoxide couldn't handle cloning from those servers.

[Byron]

It would indeed be interesting to see it drop support for an older version of something. Did they ever do that before?

What might help the conversation is that also I wouldn’t rip out V1 support in the moment V2 becomes the default as there would really be no gain. The only trigger I could imagine is having to fix V1 bugs, but fixes might well be contributed so it won’t be me to get annoyed by V1 😅.

In any case, I will do my best to keep support around as long as possible.

[joshtriplett]

On Mon, Oct 12, 2020 at 05:23:11AM -0700, Sebastian Thiel wrote:

It would indeed be interesting to see it drop support for an older version of something. Did they ever do that before?

git has made a few slow evolutions and format changes, I believe, yes.

What might help the conversation is that also I wouldn’t rip out V1 support in the moment V2 becomes the default as there would really be no gain. The only trigger I could imagine is having to fix V1 bugs, but fixes might well be contributed so it won’t be me to get annoyed by V1 😅.

In any case, I will do my best to keep support around as long as possible.

Hopefully it won't become annoying before it becomes vanishingly rare in the wild.

[Byron]

Let's not drop support in the client, by now the overhead for that seems negligible. Furthermore, push is still using V1 so it's probably a good exercise keep V1 in mind for fetches as well.