combo-layer + merge requests
cover combo-layer + merge requests
We are using combo-layer with repos hosted on Github, and we use the "merge pull request" button from Github to import changes. This leads to merge commits in our component history. Because we avoid conflict resolution during merging, that mostly works, except for two edge cases:
1. last_revision not recent enough for the next combo-layer run, patch available
2. a merge succeeds automatically (three-way merge), but "git am" then is more picky and rejects patches which do not apply cleanly. No solution for that yet; we'll have to be more careful about rebasing before merging.
The following changes since commit 2258345e19efff7717fe19a5026ec55f1b6f90b6:
oe-selftest: devtool: add a proper test to see if tap devices exist (2015-05-07 14:59:15 +0100)
are available in the git repository at:
git://github.com/pohly/openembedded-core master
https://github.com/pohly/openembedded-core/tree/master
Patrick Ohly (1):
combo-layer: improve merge commit handling
scripts/combo-layer | 27 ++++++++++++++++++++++++--- 1 file changed, 24 insertions(+), 3 deletions(-)
Signature · 1 line
2.1.4
PATCH 1/1 combo-layer: improve merge commit handling
When the head of a branch is a merge commit, combo-layer did not record that commit as last_revision because it only considers applied patches, and the merge commit never gets applied.
This causes problems when the merge commit leads to multiple patches and the commit id that gets recorded only reaches some of these patches. The next run then will try to re-apply the other patches.
This special case is now detected and dealt with by bumping last_revision to the branch commit. The behavior where the head is a normal commit is intentionally not changed, because some users might prefer the traditional behavior.
--- scripts/combo-layer | 27 ++++++++++++++++++++++++--- 1 file changed, 24 insertions(+), 3 deletions(-)
scripts/combo-layer +24 -3
@@ -731,6 +731,10 @@ def apply_patchlist(conf, repos): if line: patchlist.append(line) + ldir = conf.repos[name]['local_repo_dir'] + branch = conf.repos[name].get('branch', "master") + branchrev = runcmd("git rev-parse %s" % branch, ldir).strip() + if patchlist: logger.info("Applying patches from %s..." % name) linecount = len(patchlist)
@@ -758,11 +762,28 @@ def apply_patchlist(conf, repos): sys.exit(0) prevrev = lastrev i += 1 + # Once all patches are applied, we should update + # last_revision to the branch head instead of the last + # applied patch. The two are not necessarily the same when + # the last commit is a merge commit or when the patches at + # the branch head were intentionally excluded. + # + # If we do not do that for a merge commit, the next + # combo-layer run will only exclude patches reachable from + # one of the merged branches and try to re-apply patches + # from other branches even though they were already + # copied. + # + # If patches were intentionally excluded, the next run will + # present them again instead of skipping over them. This + # may or may not be intended, so the code here is conservative + # and only addresses the "head is merge commit" case. + if lastrev != branchrev and \ + len(runcmd("git show --pretty=format:%%P --no-patch %s" % branch, ldir).split()) > 1: + lastrev = branchrev else: logger.info("No patches to apply from %s" % name) - ldir = conf.repos[name]['local_repo_dir'] - branch = conf.repos[name].get('branch', "master") - lastrev = runcmd("git rev-parse %s" % branch, ldir).strip() + lastrev = branchrev if lastrev != repo['last_revision']: conf.update(name, "last_revision", lastrev)
Signature · 1 line
2.1.4