Accept all refspecs that implement AsRef<str>

[pluehne]

This changes the signature of the Remote::fetch and Remote::push methods to accept refspecs as slices over not only &str but anything that implements AsRef<str> (as well as IntoCString and Clone). In this way, refspecs can be provided, for example, by a &Vec<String>, which wasn’t possible before.

The reason I’d like to contribute this change is that I’m in a situation where I retrieve remote references with RemoteConnection::list and turn them into a list of refspecs I want to fetch (or push), leaving me with a Vec<String> of refspecs. However, in order to call Remote::fetch (or Remote::push), I currently have to allocate a new Vec<&str> from this Vec<String>, which I’d like to avoid if possible.

I’m still in the process of learning Rust, so I hope that this change and my explanations make sense 🙂. As far as I can tell, it’s not a breaking change in the sense that existing code using Remote::fetch and Remote::push should still be working.

[alexcrichton]

Thanks for this!

Due to this being a breaking change with respect to type inference though I'm gonna hold off on merging for now until the next breaking change for git2 is queued up

[pluehne]

@alexcrichton: Great, I’m happy to hear that this changed is queued for the next API-breaking release!

Talking about other breaking changes to bundle with this one, I’m starting to think that it may make sense to look for other places in git2 that could benefit from accepting AsRef<str> arguments rather than plain &str arguments—for consistency and in order to avoid breaking the API twice when once would do.

Remote::download comes to mind for example:

git2-rs/src/remote.rs

Lines 178 to 182 in e7973c4

	pub fn download(
	&mut self,
	specs: &[&str],
	opts: Option<&mut FetchOptions<'_>>,
	) -> Result<(), Error> {

Generally, I feel that AsRef<str> is mostly useful in situations where we’d otherwise deal with &[&str] because having to reallocate arrays or vectors of something like String just to match the &[&str] parameter type is costly. What do you think?

[alexcrichton]

Makes sense to me!

[pluehne]

@alexcrichton: Thanks for the feedback. I updated Remote::download accordingly. I can’t find any other occurrence of the &[&str] type in git2, so should we leave it at this?

[alexcrichton]

Yeah this seems fine and we can do a quick audit before the next release as well

[pluehne]

@alexcrichton: Perfect, thanks a lot!