Fix error with fetching repositories in detached state

Command `git fetch` without explicit remote name or option --all will fail
if there is no remote named "origin". And that is exactly what
arc-clone-all.sh has been doing: ARC-specific repo has been called "arc" and
optional upstream was "upstream". But even without "upstream" with a single
remote named "arc" `git fetch` still would fail. Exact error message depends
on git version, with 2.2.0 this is "No remote repository specified".

That also happens only when directory is in detached state, otherwise it
will fetch remote of current branch. Hence in the past we haven't seen this,
because arc-version.sh was deliberately checking out directory to some
branch from its detached state. That wasn't a good idea in the first place,
since first it was fetching only a random remote (subsequent `git checkout`
could have tried to checkout branch from another repository so auto-update
feature wouldn't work properly). Furthermore that was a rather clumsy
solution. During the later updates I have modified code so that it will
fetch even in detached state and that worked fine, because at not point I
had a bright idea to try this without remote named "origin" - I don't use
arc-clone-all.sh and by default git create "origin" remote during the clone.

That explains why "we cannot fetch in detached state" idea appeared in the
first place and why later I decided that it is a wrong statement in the
second place. Both of those ideas were somewhat wrong - we can fetch, but
only when conditions are met.

Two changes are done to avoid this:
- use `git fetch --all`. That would cause git to always fetch from remotes,
  regardless of what are their names, in addition that would ensure that
  required branch/tag is certainly fetched, even when they are not in the
  "origin". That is really a self-sufficient solution, that resolves the
  problem.
- arc-clone-all.sh is also modified to use "origin" name for ARC repository,
  instead of "arc". That would ensure general conformity to repositories
  created manually with git clone. I don't see reason to give ARC remote a
  special name, because we use clone, not a `git remote add`, therefore this
  is always a first remote in repository and there is surely not "origin" in
  this repository already.

Signed-off-by: Anton Kolesov <[email protected]>

Author: anthony-kolesov

arc-clone-all.sh

@@ -96,8 +96,8 @@ parse_args () {
 
 # -----------------------------------------------------------------------------
 # Function to clone a tool and (optionally) its upstream. The ARC branches of
-# the tool will be from a remote called "arc", the upstream branches from a
-# remote called "upstream".
+# the tool will be from a remote with default name ("origin"), the upstream
+# branches from a remote called "upstream".
 
 # With the creation of the binutils-gdb combined repo, the name of the repo
 # and the name of the tool are no longer the same, so we need a third argument.
@@ -130,9 +130,9 @@ clone_tool () {
 
     # Clone the ARC repo
     if [ ${is_dev} = "false" ] \
-	|| ! git clone -q -o arc ${ssh_repo} ${tool} >> ${logfile} 2>&1
+	|| ! git clone -q ${ssh_repo} ${tool} >> ${logfile} 2>&1
     then
-	if ! git clone -q -o arc ${http_repo} ${tool} >> ${logfile} 2>&1
+	if ! git clone -q ${http_repo} ${tool} >> ${logfile} 2>&1
 	then
 	    echo "Warning: Failed to clone ${http_repo}" | tee -a ${logfile}
 	    return 1

arc-versions.sh

@@ -136,8 +136,14 @@ do
     if [ "x${autopull}" = "x--auto-pull" ]
     then
 	# Fetch any new tags and branches.
+	# Note the usage of --all. Without this option and without explicit
+	# remote name `git fetch` will succeed only if there is remote named
+	# "origin", and it will fetch only it (which might be really not what
+	# is desired). And if there is no remote named "origin" then `git
+	# fetch` will fail even if there is only a single remote in git
+	# configuration.
 	echo "  fetching tags"
-	if ! git fetch --tags
+	if ! git fetch --tags --all
 	then
 	    exit 1
 	fi