cli: Refactor out get_fetch_remotes into git_util.rs

[essiene]

Similarly to git_fetch, this will be used in jj git sync, so
moving this out to maintain the same behaviour across fetch command and sync.

• Refactor out get_fetch_remotes to git_util.rs.
• inline the different get_*_remote* functions into get_fetch_remotes;
  The resulting function is still small enough to be easily readable.
• Move get_single_remote into git_util.rs and update call sites.
• Update use references

All tests still pass.

Issue: #1039

[yuja]

If both jj git sync and jj git fetch share command parameters, it might be better to extract common Args struct. Then, we can pass it in to helper functions.

[essiene]

Makes sense.

I'm thinking this could actually collapse down to something like:

let fetcher = GitFetcher::new(ui, tx, git_repo, branch, remotes, use_all_remotes);
fetcher.fetch()?;

Inside fetcher.fetch we'd grab the remotes and then do the fetch. Mainly because I can't think of a good reason why to expose to function calls to the commands instead of just one, as the intermediate result is not used by callers.

Does that feel like overkill?

In the meantime, I'm thinking to merge this PR and make changes in a follow-up to keep things clearer.

Let me know if you think otherwise.

[yuja]

I'm not sure. Do we have more methods than fetch()?

My concern about the current API is that it's hard to tell which String/bool argument represents which variable.

[essiene]

I'm not sure. Do we have more methods than fetch()?

I just realized we do need to expose get_fetch_remotes, since we use the result to build a message after the fetch succeeds further down.

My concern about the current API is that it's hard to tell which String/bool argument represents which variable.

I've added a FetchArgs struct that should make this better and doesn't end up feeling over designed.

wdyt?

[yuja]

I wouldn't include git2::Repository in args struct because it's not a user parameter and has different lifetime.

BTW, what I meant was to extract common clap::Args struct from GitFetchArgs. If jj git sync shares the same help messages, we can "flatten" the common Args struct into GitFetch/SyncArgs. If not, we'll need a separate parameter struct as you did.

[essiene]

I wouldn't include git2::Repository in args struct because it's not a user parameter and has different lifetime.

Removed.

BTW, what I meant was to extract common clap::Args struct from GitFetchArgs. If jj git sync shares the same help messages, we can "flatten" the common Args struct into GitFetch/SyncArgs. If not, we'll need a separate parameter struct as you did.

I've gone to flesh out a first draft of the sync command to be sure we need to share the help messages and yeah, it makes sense to share them. So I've extracted these out and flattened them back into GitFetchArgs.

Is this what you meant?

[yuja]

Is this what you meant?

yes, thanks.

[yuja]

Oh, we can't use the original args.fetch? That makes args.fetch useless..

[yuja]

Maybe FetchRemoteArgs can be extracted instead of all-in FetchArgs, but I'm not pretty sure if that makes sense. Sorry for the noise.