`gix::Url` should serialize/deserialize to string

[nrdxp]

Current behavior 😯

Currently, the default behavior of the gix::Url is to seralize as a sort of json object of it's components. Just curious if there is actually some conscious reason for this, or perhaps it is just something that got overlooked, in which case, I can maybe submit a patch for it to rectify.

Expected behavior 🤔

I don't think this is what anyone whould expect nor desire from a type representing a URL.

I am able to rectify this in my own code by using #[serde(serialize_with // ..., etc to change the behavior, but it is a bit tedious when using the Url in multiple places. I think the most intuitive approach is to seralize and deserialize to a string representation of a URL, since that is primarily what a URL is.

Git behavior

not strictly relevant

Steps to reproduce 🕹

just serialize a gix::Url with serde and observe the output.

[Byron]

That's a great question. serde serialises everything with the default serialisation method, and that will include the password field. It will also handle non-unicode paths correctly, as BString is effectively a Vec.

When serialising to bstring, it will drop the password, and when serialising to String, it will enforce UTF8 and possibly alter paths which aren't encodable with UTF8.

From that point of view, the default serialisation should probably remain lossless.

However, I think the documentation in that regard should be improved, to mention why it is what it is, caveats (like emitting the password as well), along with mitigations.

What do you think?

[nrdxp]

So are you basically saying to keep the current behavior on the basis that we want to maintain a lossless serialization? I suppose that is a sensible default from that perspective.

Definitely though this should be clarified in the docs, and it should be pointed out how one can serialize and deserialize to a string since that is a common enough usecase. I currently have a bunch of (de)serialize_with attributes scattered on a number of my types, but I suppose I can just use a wrapper type to avoid doing that if it becomes too painful.

[Byron]

So are you basically saying to keep the current behavior on the basis that we want to maintain a lossless serialization?

That's right.

And I have kick-started the documentation task here: #2223