【问题标题】:integrating vendor Android changes into aosp将供应商 Android 更改集成到 aosp
【发布时间】:2014-10-10 00:22:54
【问题描述】:

我正在尝试将 AOSP 设备更改集成到标准 AOSP 本地镜像中。这有点令人困惑,但我会尽量说清楚。

  1. 我在服务器(不同的本地计算机)上创建了 AOSP 存储库的本地镜像

  2. 供应商补丁基于标签“android-4.3_r2.1”。所以我初始化了一个本地 repo 并修改了 manifest 文件。

repo init -u ssh://localserver/git/aosp/mirror/platform/manifest -b android-4.3_r2.1

将 .repo/manifest.xml 修改如下:

  <remote  name="aosp"
           fetch="ssh://localserver/git/aosp/mirror" />  
  <default revision="refs/tags/android-4.3_r2.1"
           remote="aosp"
           sync-j="8" />
  1. “repo 同步”成功完成。应用了供应商提供的补丁。这为补丁修改和/或添加的每个 git 项目创建了一个分支“供应商”。

  2. 现在我有一个基于标签“android-4.3_r2.1”的仓库,一些项目有一个分支“供应商”。所有项目都没有“主”分支!

您如何将所有这些整合在一起以创建一个可行的存储库?我仍在学习。这是正确的吗?

repo checkout refs/tags/android-4.3_r2.1
repo forall -c git checkout -b master
repo forall -c git merge vendor
  1. 最后一个问题是使用 repo 将更改推送到我们的本地镜像。看来 repo 上传仅在您使用 gerrit 服务器时才有效。这真的有必要吗?

TIA

【问题讨论】:

    标签: git android-source git-repo


    【解决方案1】:

    无需更改清单以指向您的 Git 服务器。 android-4.3_r2.1 清单中的 .. URL 意味着 git URL 将相对于清单的 URL。换句话说,如果您从本地镜像克隆清单,那么剩余的 git 也会从您的本地镜像中获取。

    当您谈论供应商和主分支时,我假设您谈论的是本地分支(即在 git branch 输出中可见)。在这个答案中,我将忽略这些,只讨论遥控器上的分支。他们才是最重要的。使用 Repo,默认情况下您不会获得任何本地分支,任何本地分支的名称取决于每个人。

    我很确定您的每个项目都有一个主分支——在“aosp”远程。我建议您为您的改编和从供应商处获得的补丁选择另一个分支名称。事实上,完全选择不同的命名空间是明智的。如果您的公司或组织名为 Acme,您可以将所有分支放在 acme/ 下,例如 acme/master、acme/vendor 等。 (我更喜欢反过来做,即将上游分支填充到单独的命名空间中,如 aosp/ 和 caf/。这样你实际工作的分支没有前缀,你可以有多个上游。)

    将所有这些都放入工作存储库将涉及更新清单以指向您正在处理的分支。如果您将本地供应商分支推送到 acme/vendor,那么清单应该指向 acme/vendor。是否在每个 git 中创建一个 acme/vendor 分支并更改清单中的默认修订版,或者您是否只想将分支推送到它实际需要存在的地方并选择性地覆盖这些 git 的修订版,这取决于您。

    后者显然要求您在每次分支 git 时更新清单。另一方面,您不会在所有 git 中乱扔不必要的分支,您可以快速浏览清单文件并查看哪些 git 是分支,哪些直接来自上游。此外,如果您对所有 git 进行分支,从上游获取新版本可能需要更多工作。请记住,上游可能会切换到 git 的另一个分支,因此即使对于您没有接触过的 git,您也可能会获得非快进更新。下面的示例显示了如何无法将 acme/master 从 1.2.3 更新到 1.2.4 作为快进,因此您要么必须进行非快进更新(通常不推荐),要么从 1.2 合并。 3 进入 acme/master(可能导致冲突和永远无法进行快进更新),或者基于 1.2.4 创建一个新分支。

             -----1.2.3 (acme/master)     -----1.2.4
            /                            /
     ------------------------------------
    

    不要忘记对清单进行分支。 Repo 以一种特殊的方式处理清单 git,它假定所有更改都在名为“default”的分支上进行。因此,只需编辑清单文件,提交您的更改,然后使用例如推送它。 git push origin HEAD:refs/heads/acme/master。之后,您可以使用repo init -u ... -b acme/master 初始化一个新工作区。

    是的,repo upload 与 Gerrit 一起使用,您当然不需要它(尽管我推荐它的代码审查功能)。你可以像往常一样使用 Git 推送。我看到您已经找到了非常有用的repo forall 命令。

    【讨论】:

    • 将现有分支移动到新命名空间的最简单方法是什么?
    • 我正在考虑创建一个新的清单并更新所有引用。当一个目录是一个需要分支的新项目时并不明显。使用 repo 分支所有内容而不用担心会不会更容易?
    • 要移动分支,我假设服务器上裸 git 中的 git branch -m 工作正常。您也可以从 git 的克隆中推送,但必须一键创建新分支,一键删除旧分支 (git push origin refs/heads/foo:refs/heads/acme/foo &amp;&amp; git push origin :refs/heads/foo)。通配符也可以使用 (origin/*:refs/heads/acme/*)。
    • 当然,分支一切也很好。这主要是一个偏好问题。如果您始终对所有 git 进行分支,那么清单更新将更少,但从上游获取新版本将是更多工作。请记住,上游可能会切换到 git 的另一个分支,因此您可能会获得非快进更新。当然,没有什么是无法解决的,但可能需要人工注意。我也会稍微更新答案以提及这一点。
    猜你喜欢
    • 2014-10-16
    • 1970-01-01
    • 2020-08-23
    • 2017-05-04
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多