diff options
| author | Martin Afanasjew | 2015-12-13 00:25:53 +0100 |
|---|---|---|
| committer | Martin Afanasjew | 2016-01-04 16:25:32 +0100 |
| commit | cc632acd07d0884d51c5de414fcabd6e5f856fd2 (patch) | |
| tree | 20707242b9e63fb235f7007b9f8b924d205dd6a9 /Library/Homebrew/test | |
| parent | 47afde940a70f2a3a597f01bf52f1b8ad096e65f (diff) | |
| download | brew-cc632acd07d0884d51c5de414fcabd6e5f856fd2.tar.bz2 | |
update: avoid unnecessarily recreating 'master'
This only affects the behavior of `brew update` while being on a branch
`feature` that doesn't track the upstream branch. For simplicity, the
upstream branch is assumed to be called `master` (`@upstream_branch` in
the code). Consider the following simplified commit history:
master origin/master (current state of remote)
| |
A---B---C---D---E---F
\
G---H---I
|
feature (HEAD)
If `origin/master` is equal to `master` and also points at commit `C`,
then `brew update` will update both `master` and `origin/master` to `F`
and report on the changes in the range `C..F`.
However, if `origin/master` is equal to `E` because some commits have
been already fetched with `git fetch origin`, then `brew update` will
recreate `master` from `origin/master` and then pull in the commits from
the remote to update both to `F`. Because `master` gets recreated from
a younger `origin/master`, the report will only contain changes from the
range `E..F` (thus omitting the changes from `C..E`).
This commit adjusts the logic to not recreate `master` if it can be
safely fast-forwarded to `origin/master` (the common case). This fixes
the problem from the second scenario and again reports on the desired
range `C..F`.
Closes Homebrew/homebrew#46951.
Signed-off-by: Martin Afanasjew <martin@afanasjew.de>
Diffstat (limited to 'Library/Homebrew/test')
0 files changed, 0 insertions, 0 deletions
