umpf: add built-in support for synchronizing topic branches #53
Conversation
a3f
force-pushed
the
afa/umpf-push-pull-legs
branch
from
9f35a0f to
4353753
Compare
While umpf was explicitly developed with multiple developers adding
utags and sharing topic branches in mind, it is less than ideal when
there are multiple developers working on the same topic branches.
And it frequently leads to one of two issues:
- The branch is pushed before the utag is accepted into the BSP
repository and other developers get an unexpected addition to
their umpf
- The branch is not pushed after the utag is accepted into the BSP
repository and other developers get an unexpected removal from
their umpf
Every time this happens, it wastes a bit of time to identify what went
wrong and thus a solution built into umpf is appropriate:
- CI will call umpf --remote=downstream --force push $BSP/series.inc
when a PR touching a useries is accepted
- Developers can call umpf pull to synchronize their topic branches
or to find out when difference they have to the now upstream
version
Signed-off-by: Ahmad Fatoum <[email protected]>
a3f
force-pushed
the
afa/umpf-push-pull-legs
branch
from
4353753 to
b48609e
Compare
| ### command: push ### | ||
|
|
||
| resolve_commitish() { | ||
| ${GIT} rev-parse --revs-only "$@" 2>/dev/null |
| } | ||
|
|
||
| shorten_commitish() { | ||
| resolve_commitish --short ${1} |
There was a problem hiding this comment.
Quote arguments everywhere.
|
|
||
| update_local() { | ||
| local success=false args="${1}" | ||
| local opts |
| while read -r line; do | ||
| local prefix="" suffix="" | ||
|
|
||
| eval set -- ${line} |
There was a problem hiding this comment.
local a b c
read -r a b c <<< "${line}"
Use better variable names but you get the idea. This avoids other expansions.
Or use read -r -a array_var ... but I think individual variables make this more readable,
| done <<< "$args" | ||
|
|
||
| while read -r line; do | ||
| eval set -- ${line} |
| local rtagrev="$(resolve_tag "${remote}" ${tagname})" | ||
| local rtagrevf="$(resolve_commitish ${rtagrev}^)" | ||
| if [ "$tagrevf" != "$rtagrevf" ]; then | ||
| if [ -z "$rtagrevf" ]; then | ||
| abort "${remote}${remote:+/}refs/tags/$tagname not found" | ||
| else | ||
| abort "${remote}${remote:+/}refs/tags/$tagname" \ | ||
| "has unexpected commit-ish $rtagrev" | ||
| fi | ||
| fi |
There was a problem hiding this comment.
Skip for emtpy remote? In that case you're comparing the same tag, right?
| fi | ||
|
|
||
| local rtagrev="$(resolve_tag "${remote}" ${tagname})" | ||
| local rtagrevf="$(resolve_commitish ${rtagrev}^)" |
There was a problem hiding this comment.
use resolve_tag here as well to make it less confusing.
| commit="refs/tags/$tag" | ||
| fi | ||
|
|
||
| resolve_commitish "${commit}^{}" |
There was a problem hiding this comment.
This is only used to compare the local and remote tags. What's the use-case for accepting different tags with the same commit?
| return | ||
| fi | ||
|
|
||
| ${GIT} push $opts ${remote} -- $args |
There was a problem hiding this comment.
I think, if you use ${GIT_DIR} as remote for the local case, you can use git push for that as well. That would avoid a lot of complexity. So try that first, it may make some of my comments obsolete.
|
|
||
| if [ -n "${remote}" ]; then | ||
| # Needed, so git rev-parse below can check for existent branches | ||
| git fetch --quiet --no-tags ${remote} 2>/dev/null |
There was a problem hiding this comment.
No, use ls-remote for the branch checks instead.
That would make a --force-with-lease possible as well (I'd like to see that as well at some point but I won't insist on it for this PR).
While umpf was explicitly developed with multiple developers adding utags and sharing topic branches in mind, it is less than ideal when there are multiple developers working on the same topic branches.
And it frequently leads to one of two issues:
The branch is pushed before the utag is accepted into the BSP repository and other developers get an unexpected addition to their umpf
The branch is not pushed after the utag is accepted into the BSP repository and other developers get an unexpected removal from their umpf
Every time this happens, it wastes a bit of time to identify what went wrong and thus a solution built into umpf is appropriate:
CI will call
umpf --remote=downstream --force push $BSP/series.incwhen a PR touching a useries is acceptedDevelopers can call
umpf pullto synchronize their topic branches or to find out when difference they have to the now upstream version