Re: Remotes order in "git remote update"

Johannes Schindelin [off-list ref] writes:

On Sun, 9 Mar 2008, Samuel Tardieu wrote:

quoted

On  9/03, Junio C Hamano wrote:

| Samuel Tardieu [off-list ref] writes:
| 
| > It looks like remote repositories are ordered alphabetically by their
| > local names when doing a "git remote update".
|
| I think the reimplementaiton in 'next' that will hopefully be in 1.5.5
| will keep the list of remotes in the order read from the config.

Indeed it does, thanks.

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...

We never guaranteed there is any order the remotes are processed.  One
order is as good as another, and the only way that can give some guarantee
is with the remote groups.  So there is no regression and the suggestion
to use remote group is one good way.

We _might_ want to start guaranteeing some orders by documenting, but I do
not think it is necessary.  Does "git config" and "git remote" code even
guarantee the order the newly added ones are stored in the $GIT_DIR/config
file, and is it by design and specified in the documentation, or it is by
accident and happens to be the way the code is written?

Hi,

On Sun, 9 Mar 2008, Junio C Hamano wrote:

We _might_ want to start guaranteeing some orders by documenting, but I 
do not think it is necessary.  Does "git config" and "git remote" code 
even guarantee the order the newly added ones are stored in the 
$GIT_DIR/config file, and is it by design and specified in the 
documentation, or it is by accident and happens to be the way the code 
is written?

git_config_set() appends to the end of the config if the section it tries 
to edit did not exist yet.  However, this is just an implementation 
detail, no design decision.

Ciao,
Dscho