Fix rbtools git client when local clone has no "origin" remote.
Review Request #10340 — Created Nov. 29, 2018 and submitted
In the case where the local clone has remotes, but none of them are
named "origin", rbtools was failing to correctly determine the most
recent upstream commit. This was the case even when a tracking branch or
parent branch associated with a remote was configured. The cause here
was a couple places where we were hardcoding "origin" instead of
attempting to detect the remote.This change fixes that by introducing a new mechanism to try to guess
the remote. If a remote tracking branch is specified, we'll prefer that,
failing back to the remote configured for the current branch. If no
direct association can be found, we'll return either "origin" or fall
back on the first remote found, emitting a warning.
- Ran unit tests.
- Set up a clone with multiple remotes, none of which were named
"origin". Saw that I could correctly post changes when branch remotes
and/or TRACKING_BRANCH were set correctly.
Description | From | Last Updated |
---|---|---|
These private methods are before some public methods. They should be moved further down the class. |
chipx86 | |
Must be the full path to the exception. Also, the description needs to be indented one more level. |
chipx86 | |
This is kind of weirdly formatted. Should be the standard: all_remote_branches = [ branch.strip() for branch in self._execute(['git', 'branch', '--remotes'], … |
chipx86 | |
Let's specifically say "in .reviewboardrc". |
chipx86 | |
Missing period. |
chipx86 |
- Commit:
-
69776c0bb66f07efd9514f897d493e93dcbafec481c9b4f0560f107eb92b097847fd1ef0fd63abe0
- Diff:
-
Revision 2 (+86 -20)