Hi, On Mon, 10 Mar 2008, Samuel Tardieu wrote: > On 9/03, Johannes Schindelin wrote: > > | Well, technically this is a regression. > | > | If you really want to order your remotes, why not add something like > | > | [remotes] > | default = my-first-remote my-second-remote [...] > | > | to the config? That is what the (recently fixed in builtin-remote) > | remote groups are for... > > I could do that, but it means that if I add a new remote, it won't enter > the default group by itself since I defined it explicitely. I think > respecting the order given in the .git/config file when not using a > group doesn't hurt and may help. Well, since the builtin remote does that, I do not see a reason to change it ;-) However, I do not see a reason to guarantee that, either. > Or maybe we should add a remotes.reference configuration variable which > lists the remote to use first if it belongs to the list of remotes we > are going to fetch from. Or at least, make origin the first fetched > remote, but I know some projects where origin uses a dumb protocol while > other contributors have up-to-date non-dumb public repositories. I do not like the remotes.reference idea. Too specific for one particular use case. Ciao, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
