t5505-remote fails on Windows
I see this failure related to 'git remote show':
* expecting success:
(cd test &&
git config --add remote.origin.fetch
refs/heads/master:refs/heads/upstream &&
git fetch &&
git checkout -b ahead origin/master &&
echo 1 >> file &&
test_tick &&
git commit -m update file &&
git checkout master &&
git branch --track octopus origin/master &&
git branch --track rebase origin/master &&
git branch -d -r origin/master &&
git config --add remote.two.url ../two &&
git config branch.rebase.rebase true &&
git config branch.octopus.merge "topic-a topic-b topic-c" &&
(cd ../one &&
echo 1 > file &&
test_tick &&
git commit -m update file) &&
git config --add remote.origin.push : &&
git config --add remote.origin.push
refs/heads/master:refs/heads/upstream &&
git config --add remote.origin.push +refs/tags/lastbackup &&
git config --add remote.two.push
+refs/heads/ahead:refs/heads/master && git config --add remote.two.push
refs/heads/master:refs/heads/another &&
git remote show origin two > output &&
git branch -d rebase octopus &&
test_cmp expect output)>From d:/Src/mingw-git/t/trash directory.t5505-remote/one
* [new branch] master -> upstream
Branch ahead set up to track remote branch refs/remotes/origin/master.
Switched to a new branch "ahead"
[ahead 847549e] update
1 files changed, 1 insertions(+), 0 deletions(-)
Switched to branch "master"
Branch octopus set up to track remote branch refs/remotes/origin/master.
Branch rebase set up to track remote branch refs/remotes/origin/master.
Deleted remote branch origin/master (9d34b14).
[master 6329a3c] update
1 files changed, 1 insertions(+), 0 deletions(-)
error: src refspec refs/tags/lastbackup does not match any.
Deleted branch rebase (9d34b14).
Deleted branch octopus (9d34b14).
--- expect Wed Mar 18 11:22:53 2009
+++ output Wed Mar 18 11:22:54 2009
@@ -12,8 +12,8 @@
and with remote topic-c
rebase rebases onto remote master
Local refs configured for 'git push':
- master pushes to master (local out of date)
master pushes to upstream (create)
+ master pushes to master (local out of date)
* remote two
URL: ../two
HEAD branch (remote HEAD is ambiguous, may be one of the following):
* FAIL 8: show
As you can see, the entries for "master pushes to..." are reversed. It
seems that this output is not stable. Before I delve into this, do you
know whether there is some data structure involved that does not guarantee
the order? Such as a hash table, a opendir/readdir sequence, or perhaps
while reading the config file?
It looks like we have to explicitly sort the list somewhere.
-- Hannes