Hello,
Here at Linaro, we pull components for Android builds from various sources, like AOSP upstream, our forks of AOSP components (to fix compatibility issues with gcc 4.5/4.6, etc.), bootloaders and kernels from SoC support teams, etc. All in all, that means that we don't have full control over those repositories for example to tag them.
So, to achieve build reproducibility, we decided to use a feature that repo provides, exporting "release" manifest for a build using "repo manifest -r", which dumps manifest with SHA1 revision ids of components used for particular build.
However, we found that such release manifests are not robust over time. If an upstream project uses rebase work model, then, even if a particular revision was tagged which ensures that this revision won't be garbage-collected if rebased later in main branch, the repo tool may not be able to fetch it.
This happens because, unlike git clone, the repo tool limits what it fetches to refs/heads/*. So, if some revision is not reachable from one of branches (but still reachable from refs/tags/*), it will lead to an error like:
error.GitError: boot/u-boot-linaro-stable update-ref: error: Trying to write ref refs/remotes/m/linaro_android_2.3.3 with nonexistant object 9736a9332fcfe5fef1361a6d91740e160ad04bd5 fatal: Cannot update the ref 'refs/remotes/m/linaro_android_2.3.3'.
So, we would like to know if this can be considered a bug (it looks pretty much such for us, after all, we're just trying to feed up repo with what it generated, while 100% having valid revisions in the underlying repositories), and can be fixed. The patch would be pretty simple:
diff --git a/project.py b/project.py index 9d67dea..31ee90f 100644 --- a/project.py +++ b/project.py @@ -1369,7 +1374,7 @@ class Project(object): else: ref_dir = None
- cmd = ['fetch'] + cmd = ['fetch', '--tags']
# The --depth option only affects the initial fetch; after that we'll do # full fetches of changes.