Re: [egit-dev] RFC: JGit - RemoteConfig API is misleading

[Shawn Pearce <spearce@xxxxxxxxxxx>]

On Wed, Apr 7, 2010 at 1:16 AM, Kinzler, Mathias
<mathias.kinzler@xxxxxxx> wrote:
> Currently, RemoteConfig keeps two lists of URIs, one for fetch and one for
> push-URIs. However, the corresponding list of RefSpecs make only sense for a
> given URI. In other words, mixing RefSpecs for different remote repositories
> does not make sense IMHO.

This is actually part of the configuration standard supported by C
Git.  Linus invented it a while ago so that he could configure a
remote which multiple URIs and running `git push remote` would loop
through each of those URIs and send the same branches to all of them.
This is very useful when you have multiple public repositories like
Junio Hamano has for git.git, or when you want to publish to both a
couple of backup systems at the same time.  I do the latter.

However for fetch only the first URI is used.  So yea, its misleading
and confusing, but its the data model we are getting from the
configuration file.  An end-user who has used the C implementation and
configured a remote with multiple URIs and then pushes to it from
within EGit should expect us to have the same behavior as the C code,
that is to push to all of the remotes and report back the final
status.

> Thus I would suggest to have RemoteConfig have two URI members, one for a
> fetch URI and one for a push URI and adjust the API accordingly by removing
> the list-based operations for URIs and provide simple setter/getter methods
> as replacement.

We could add a simple get/set to affect the first URI.  But
applications would need to be careful about the semantics of setting
the URI when there are multiple URIs present.  Should the set just
replace the first?  Or overwrite the entire list?  It clearly depends
on what the user intended when they asked the application to set the
URI.


In hindsight, maybe the multiple URIs per remote idea is crazy to have
in the C implementation.  But like I said above, I actually use it, as
does Junio Hamano and Linus Torvalds.  So the top 3 folks who have
contributed to the C code would miss this feature if it was removed.
So maybe its worthwhile, even though it doesn't make that much sense.
:-)

-- 
Shawn.