[bitbake-devel] [RFC 0/5] Git fetcher changes for resolving tags

[Olof Johansson]

Hi,

We use the git fetcher for our internal recipes, and we are supplying
;tag=<tag> to the SRC_URI. As the tag doesn't look like a sha1 hash, bitbake
treats this as a branch name. After the changes that made bitbake verify that a
commit is present on the specified branch, this led to errors. Richard fixed
this issue, in a patch included in this patch series.

Additionally, the change also uncovered issues we had with git ls-remote not
returning the sha1 we expect, in cases where a branch ends with the tag name
you are looking for, for instance:

$ git ls-remote <url> v1.2.3
981e76c984cb5513be7e8d1b7e3cab979c3a957e        refs/heads/foo/v1.2.3
dc171f81eebc887f72a2a973f5e5fc54ce1bbaca        refs/tags/v1.2.3

The current _latest_revision implementation would just do .split()[0], and
happily return 981e76c. My suggested solution is to first try
refs/tags/v1.2.3^{} and then move on to refs/heads/v1.2.3. This changes the
behavior for the cases were either a branch or a tag is specified: you would
never get the foo/v1.2.3 branch, as it's not an exact match.


Also in this patch series is a unit test suite for the git fetcher and some
minor refactoring of the fetcher itself. These tests should complement the more
high level tests already present in bb.tests.fetch.


Olof Johansson (4):
  bb.fetch2.git: reuse basecmd attribute
  bb.tests.fetch_git: initial set of tests for git fetcher
  bb.fetch2.git: support resolving both tags and branches
  bb.fetch2.git: use the _gen_git_url() function

Richard Purdie (1):
  fetch2/git: Improve handling of unresolved names verses branches

 bin/bitbake-selftest      |   3 +-
 lib/bb/fetch2/git.py      | 104 ++++++++++++++-----
 lib/bb/tests/fetch_git.py | 259 ++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 337 insertions(+), 29 deletions(-)
 create mode 100644 lib/bb/tests/fetch_git.py

-- 
1.8.4.rc3