Use repo init -b for branch switching.

Now that repo is upgraded to 1.9.4, re-init no longer needs to delete
the 'default' branch - repo does this by itself.  There are some
known oddities with this support as of v1.9.4- that said there is
some known breakages from the previous approach; see:
https://groups.google.com/forum/?fromgroups#!msg/repo-discuss/4WmUJ2ttN8o/ssYVLO5TCVYJ
for examples.

That's being tracked upstream and the outstanding issues are suppressed
via this patch.

Additionally, in heavy testing, the cbuildbot/repo interaction that
lead to the manifest on detached HEAD *cannot* be replicated against
ToT chromite, nor this CL; in light of how that occurred in the past,
it's being chalked up as caused by a mixture of cbuildbot bugs (inability
to recover from badly timed failures between init and sync), and general
mayhem.  Can't reproduce it at the cbuildbot level, nor has it ever
been triggered at the repo level- thus viewing it as one off breakages
induced by devs involved at the time.

That said, this code *still* protects against it on the off chance more
is going on there- it'll spot the detached HEAD, warn, and fix it.

No warnings occur for a month or two, then that code likely will be
pulled.

Finally, as for the old --detach/delete route that this code is
replacing; that approach was explicitly targetted for repo <1.9.4; what
it did, was jump off the default branch since repo couldn't handle updating
an existing 'default' branch (at all) in earlier versions.  This support
was added in v1.9.4, but the underlying bugs repo has where it doesn't
fully write out the git configuration for the manifest repository occurs
more frequently now.  If curious as to the specifics of those manifest bugs,
look in cros_build_lib.GetTrackingBranchViaGitConfig; we've been working
around this sort of thing for a while now.

The core "update the branch in place" fix works fine on it's own, thus
the --detach/delete isn't needed- from a paranoia standpoint, it takes
us further off the supported repo workflow making us more likely to
encounter issues in addition (note that is *definite* paranoia also,
but a valid concern).

If things keep misbehaving despite this CL, then detach/delete, and more
stringent efforts (namely taking away more control from repo itself) will
be undertaken; this CL thus far hasn't shown a need for that however.

BUG=chromium-os:31912, chromium-os:32054
TEST=remote trybot switching branches.

Change-Id: Iab6b54e080b7cb0c239d4af735103b241b33f751
Reviewed-on: https://gerrit.chromium.org/gerrit/25447
Reviewed-by: Brian Harring <ferringb@chromium.org>
Tested-by: Brian Harring <ferringb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28418
Reviewed-by: Ryan Cui <rcui@chromium.org>
1 file changed