{"thread":{"id":"12602","subject":"Remotes order in \"git remote update\"","startedAt":"2008-03-09T10:22:33Z","lastAt":"2008-03-10T19:21:42Z","messageCount":9,"participants":["Samuel Tardieu","Junio C Hamano","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"71501","messageId":"2008-03-09-11-22-34+trackit+sam@rfc1149.net","threadId":"12602","inReplyTo":null,"subject":"Remotes order in \"git remote update\"","fromName":"Samuel Tardieu","fromEmail":"sam@rfc1149.net","sentAt":"2008-03-09T10:22:33Z","receivedAt":"2008-03-09T10:22:33Z","isPatch":false,"sender":{"key":"sam@rfc1149.net","avatar":"https://avatars.githubusercontent.com/u/44656?v=4"},"body":"It looks like remote repositories are ordered alphabetically by their\nlocal names when doing a \"git remote update\". In a project I follow,\nit has an unfortunate consequence: a dumb remote repository using\n\"http://\" is fetched first, while many commits are shared between all\nthe upstreams I follow.\n\nIf remotes were fetched using their order in .git/config, it would\nfetch from a \"git://\" remote repository first, limiting transfers from\nthe dumb remote repository. Is there a way to force the update order\nshort of changing the local names or issuing multiple fetch commands?\n\n Sam\n-- \nSamuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/\n\n"},{"id":"71504","messageId":"7vbq5op4gt.fsf@gitster.siamese.dyndns.org","threadId":"12602","inReplyTo":"2008-03-09-11-22-34+trackit+sam@rfc1149.net","subject":"Re: Remotes order in \"git remote update\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-09T10:38:26Z","receivedAt":"2008-03-09T10:38:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Samuel Tardieu writes:\n\n> It looks like remote repositories are ordered alphabetically by their\n> local names when doing a \"git remote update\".\n\nYeah, it is an unfortunate consequence of the Perl implementation that\nuses a hash to record remote and then try to give a stable ordering by\nsorting keys. The command originally was never intended for working on\nmore than one remote, but addition of \"remote update\" could have been done\nto follow the order in the configuration.\n\nI think the reimplementaiton in 'next' that will hopefully be in 1.5.5\nwill keep the list of remotes in the order read from the config.\n\n\n"},{"id":"71510","messageId":"2008-03-09-12-21-35+trackit+sam@rfc1149.net","threadId":"12602","inReplyTo":"7vbq5op4gt.fsf@gitster.siamese.dyndns.org","subject":"Re: Remotes order in \"git remote update\"","fromName":"Samuel Tardieu","fromEmail":"sam@rfc1149.net","sentAt":"2008-03-09T11:21:35Z","receivedAt":"2008-03-09T11:21:35Z","isPatch":false,"sender":{"key":"sam@rfc1149.net","avatar":"https://avatars.githubusercontent.com/u/44656?v=4"},"body":"On 9/03, Junio C Hamano wrote:\n\n| Samuel Tardieu writes:\n| \n| > It looks like remote repositories are ordered alphabetically by their\n| > local names when doing a \"git remote update\".\n|\n| I think the reimplementaiton in 'next' that will hopefully be in 1.5.5\n| will keep the list of remotes in the order read from the config.\n\nIndeed it does, thanks.\n\n"},{"id":"71525","messageId":"alpine.LSU.1.00.0803092148480.3975@racer.site","threadId":"12602","inReplyTo":"2008-03-09-12-21-35+trackit+sam@rfc1149.net","subject":"Re: Remotes order in \"git remote update\"","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-03-09T20:50:04Z","receivedAt":"2008-03-09T20:50:04Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 9 Mar 2008, Samuel Tardieu wrote:\n\n> On 9/03, Junio C Hamano wrote:\n> \n> | Samuel Tardieu writes:\n> | \n> | > It looks like remote repositories are ordered alphabetically by their\n> | > local names when doing a \"git remote update\".\n> |\n> | I think the reimplementaiton in 'next' that will hopefully be in 1.5.5\n> | will keep the list of remotes in the order read from the config.\n> \n> Indeed it does, thanks.\n\nWell, technically this is a regression.\n\nIf you really want to order your remotes, why not add something like\n\n[remotes]\n\tdefault = my-first-remote my-second-remote [...]\n\nto the config? That is what the (recently fixed in builtin-remote) remote \ngroups are for...\n\nCiao,\nDscho\n"},{"id":"71552","messageId":"7vbq5nm8k1.fsf@gitster.siamese.dyndns.org","threadId":"12602","inReplyTo":"alpine.LSU.1.00.0803092148480.3975@racer.site","subject":"Re: Remotes order in \"git remote update\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-10T05:50:38Z","receivedAt":"2008-03-10T05:50:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Sun, 9 Mar 2008, Samuel Tardieu wrote:\n>\n>> On 9/03, Junio C Hamano wrote:\n>> \n>> | Samuel Tardieu writes:\n>> | \n>> | > It looks like remote repositories are ordered alphabetically by their\n>> | > local names when doing a \"git remote update\".\n>> |\n>> | I think the reimplementaiton in 'next' that will hopefully be in 1.5.5\n>> | will keep the list of remotes in the order read from the config.\n>> \n>> Indeed it does, thanks.\n>\n> Well, technically this is a regression.\n>\n> If you really want to order your remotes, why not add something like\n>\n> [remotes]\n> \tdefault = my-first-remote my-second-remote [...]\n>\n> to the config? That is what the (recently fixed in builtin-remote) remote \n> groups are for...\n\nWe never guaranteed there is any order the remotes are processed. One\norder is as good as another, and the only way that can give some guarantee\nis with the remote groups. So there is no regression and the suggestion\nto use remote group is one good way.\n\nWe _might_ want to start guaranteeing some orders by documenting, but I do\nnot think it is necessary. Does \"git config\" and \"git remote\" code even\nguarantee the order the newly added ones are stored in the $GIT_DIR/config\nfile, and is it by design and specified in the documentation, or it is by\naccident and happens to be the way the code is written?\n"},{"id":"71561","messageId":"2008-03-10-09-17-33+trackit+sam@rfc1149.net","threadId":"12602","inReplyTo":"alpine.LSU.1.00.0803092148480.3975@racer.site","subject":"Re: Remotes order in \"git remote update\"","fromName":"Samuel Tardieu","fromEmail":"sam@rfc1149.net","sentAt":"2008-03-10T08:17:33Z","receivedAt":"2008-03-10T08:17:33Z","isPatch":false,"sender":{"key":"sam@rfc1149.net","avatar":"https://avatars.githubusercontent.com/u/44656?v=4"},"body":"On 9/03, Johannes Schindelin wrote:\n\n| Well, technically this is a regression.\n| \n| If you really want to order your remotes, why not add something like\n| \n| [remotes]\n| \tdefault = my-first-remote my-second-remote [...]\n| \n| to the config? That is what the (recently fixed in builtin-remote) remote \n| groups are for...\n\nI could do that, but it means that if I add a new remote, it won't enter\nthe default group by itself since I defined it explicitely. I think\nrespecting the order given in the .git/config file when not using a\ngroup doesn't hurt and may help.\n\nOr maybe we should add a remotes.reference configuration variable which\nlists the remote to use first if it belongs to the list of remotes we\nare going to fetch from. Or at least, make origin the first fetched\nremote, but I know some projects where origin uses a dumb protocol while\nother contributors have up-to-date non-dumb public repositories.\n"},{"id":"71574","messageId":"alpine.LSU.1.00.0803101211000.3975@racer.site","threadId":"12602","inReplyTo":"7vbq5nm8k1.fsf@gitster.siamese.dyndns.org","subject":"Re: Remotes order in \"git remote update\"","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-03-10T11:11:51Z","receivedAt":"2008-03-10T11:11:51Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 9 Mar 2008, Junio C Hamano wrote:\n\n> We _might_ want to start guaranteeing some orders by documenting, but I \n> do not think it is necessary. Does \"git config\" and \"git remote\" code \n> even guarantee the order the newly added ones are stored in the \n> $GIT_DIR/config file, and is it by design and specified in the \n> documentation, or it is by accident and happens to be the way the code \n> is written?\n\ngit_config_set() appends to the end of the config if the section it tries \nto edit did not exist yet. However, this is just an implementation \ndetail, no design decision.\n\nCiao,\nDscho\n"},{"id":"71575","messageId":"alpine.LSU.1.00.0803101212220.3975@racer.site","threadId":"12602","inReplyTo":"2008-03-10-09-17-33+trackit+sam@rfc1149.net","subject":"Re: Remotes order in \"git remote update\"","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-03-10T11:13:43Z","receivedAt":"2008-03-10T11:13:43Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 10 Mar 2008, Samuel Tardieu wrote:\n\n> On 9/03, Johannes Schindelin wrote:\n> \n> | Well, technically this is a regression.\n> | \n> | If you really want to order your remotes, why not add something like\n> | \n> | [remotes]\n> | \tdefault = my-first-remote my-second-remote [...]\n> | \n> | to the config? That is what the (recently fixed in builtin-remote) \n> | remote groups are for...\n> \n> I could do that, but it means that if I add a new remote, it won't enter \n> the default group by itself since I defined it explicitely. I think \n> respecting the order given in the .git/config file when not using a \n> group doesn't hurt and may help.\n\nWell, since the builtin remote does that, I do not see a reason to change \nit ;-) However, I do not see a reason to guarantee that, either.\n\n> Or maybe we should add a remotes.reference configuration variable which \n> lists the remote to use first if it belongs to the list of remotes we \n> are going to fetch from. Or at least, make origin the first fetched \n> remote, but I know some projects where origin uses a dumb protocol while \n> other contributors have up-to-date non-dumb public repositories.\n\nI do not like the remotes.reference idea. Too specific for one particular \nuse case.\n\nCiao,\nDscho\n"},{"id":"71607","messageId":"7v3aqyjsft.fsf@gitster.siamese.dyndns.org","threadId":"12602","inReplyTo":"alpine.LSU.1.00.0803101212220.3975@racer.site","subject":"Re: Remotes order in \"git remote update\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-10T19:21:42Z","receivedAt":"2008-03-10T19:21:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Mon, 10 Mar 2008, Samuel Tardieu wrote:\n>\n>> On 9/03, Johannes Schindelin wrote:\n>> \n>> | Well, technically this is a regression.\n>> | \n>> | If you really want to order your remotes, why not add something like\n>> | \n>> | [remotes]\n>> | \tdefault = my-first-remote my-second-remote [...]\n>> | \n>> | to the config? That is what the (recently fixed in builtin-remote) \n>> | remote groups are for...\n>> \n>> I could do that, but it means that if I add a new remote, it won't enter \n>> the default group by itself since I defined it explicitely. I think \n>> respecting the order given in the .git/config file when not using a \n>> group doesn't hurt and may help.\n>\n> Well, since the builtin remote does that, I do not see a reason to change \n> it ;-) However, I do not see a reason to guarantee that, either.\n\nI think it is a reasonable expectation that, if you have these in the\nconfiguration file (not limited to \"remotes\" but for a random \"a\"):\n\n\t[a \"foo\"]\n \tx = \"frotz\"\n x = \"xyzzy\"\n\t[a \"bar\"]\n \tx = \"nitfol\"\n x = \"rezrov\"\n\nsomething that _iterates_ over a.*.* would see them in the order of\nappearance (foo.frotz, foo.xyzzy, bar.nitfol and then bar.rezrov).\n\nIf you need both iterable and also quick lookup (e.g. when there can be\nthousands of \"foo\" and \"bar\" for a particular \"a\" and it is common to ask\nfor \"a.$name.x\" for random $name), the config reader for \"a\" needs to\nhave an implementation that is better than just a naive linear list.\nMaybe it can use a hashed table whose entry records the appearance order\nin the configuration file, expecting that a look-up is far more common\noperation than enumeration, and when somebody asks you to enumerate, you\ncan create a sorted list on-demand and iterate on that. The\nimplementation would be different depending on the expected usage pattern,\nbut I do not see much to gain for us by reserving the right to enumerate\nthings in a random order.\n"}]}