mirror of
https://github.com/odoo/runbot.git
synced 2025-03-15 15:35:46 +07:00
60188063f8
Today (or really a month ago) I learned: when giving git a symbolic ref (e.g. a ref name), if it's ambiguous then 1. If `$GIT_DIR/$name` exists, that is what you mean (this is usually useful only for `HEAD`, `FETCH_HEAD`, `ORIG_HEAD`, `MERGE_HEAD`, `REBASE_HEAD`, `REVERT_HEAD`, `CHERRY_PICK_HEAD`, `BISECT_HEAD` and `AUTO_MERGE`) 2. otherwise, `refs/$name` if it exists 3. otherwise, `refs/tags/$name` if it exists 4. otherwise, `refs/heads/$name` if it exists 5. otherwise, `refs/remotes/$name` if it exists 6. otherwise, `refs/remotes/$name/HEAD` if it exists This means if a tag and a branch have the same name and only the name is provided (not the full ref), git will select the tag, which gets very confusing for the mergebot as it now tries to rebase onto the tag (which because that's not fun otherwise was not even on the branch of the same name). Fix by providing full refs to `rev-parse` when trying to retrieve the head of the target branches. And as a defense in depth opportunity, also exclude tags when fetching refs by spec: apparently fetching a specific commit does not trigger the retrieval of tags, but any sort of spec will see the tags come along for the ride even if the tags are not in any way under the fetched ref e.g. `refs/heads/*` will very much retrieve the tags despite them being located at `refs/tags/*`. Fixes #922 |
||
|---|---|---|
| .. | ||
| changelog | ||
| data | ||
| migrations | ||
| models | ||
| tests | ||
| __init__.py | ||
| __manifest__.py | ||
| controllers.py | ||