将子模块更新为最新版本，而不会累积更新历史记录 [英] Updating submodules to their latest without accumulating update history

问题描述

使用子模块--remote 更新子模块将拉入子模块的HEAD，而不是在包装git回购中记录的散列。但看起来，包装git回购将继续管理它们本身的散列，不必要地将噪音引入它自己的历史。

b
$ b

在子模块更新--remote 之后，将在包装项目中引入更改，如：

<$ p $
（使用git add< file> ...来更新将提交的内容）
（使用git checkout - < ; file> ...放弃工作目录中的更改）

修改：< module-name> （新提交）

是否可能不包含任何散列或有关子模块散列的信息一个包含子模块的git仓库，这样子模块更新不会引入新提交的需求，并且不会反映到项目的历史记录中？

激励场景：

这可以解决一个工作流程，可以描述为始终使用最新的所有子模块，目前需要特殊管理每个子模块更新（提交或以某种方式从历史记录中删除上述更改记录..当您只想使用最新版本时，这会使工作流程非常混乱）。

解决方案

长答案

包括任何散列或有关子模块散列的信息

不，这是子模块的 all ：录入父级回购一个固定 SHA1（即 gitlink ， 索引中的特殊条目）。

为了方便起见，您可以更新子模块的内容以匹配子模块上游回购的远程分支。

（ git submodule update --remote ）

但是，一旦更新完成，结果与子模块内部的任何其他手动修改没有什么不同：它的SHA1更改，需要记录在父回购站中。 / p>

目标是稍后使用精确相同内容（包括其子模块内容）克隆父回购，因此子模块将被检出在他们各自的家长回购记录中记录的SHA1中。

---

提交9937e65 （Git 2.0，2014年1月）提及：

明确表示不存在隐式浮动; - remote 可以让你明确地将上游分支集成到你当前的HEAD中（就像在中运行' git pull '）子模块）。
与当前' git pull '的唯一区别是用于上游分支的配置位置和
设置，其中

commit 23d25e4 details：

此提交不会更改初始克隆后的更新逻辑，它将继续为结账模式更新创建分离的HEAD，并在其他模式下集成远程工作与本地HEAD（分离或不分离）。

改变的动机是在子模块内部进行本地工作的开发人员可能会选择非结帐模式进行更新，以便他们的本地工作与上游工作集成。

未开展本地子模块工作的开发人员坚持使用结账模式更新，因此在更新过程中任何明显的本地工作都会被吹走。例如，如果上游将远程分支或gitlinked提交回退到早期版本，则结帐模式开发人员也希望它们的旧子模块结账也会回滚，而不是通过回滚引用获得无操作合并/重新绑定。

TL; DR

git universe中可能没有任何东西可以使repo自动指向子模块的最后一个，而不是指向特定的提交散列。尽管子模块更新--remote 可以用作忽略该跟踪的约定，但描述更新的历史记录始终会记录在父回购中。

Updating submodules with submodule --remote will pull in the HEAD of the submodules rather than the hash recorded within the wrapping git repo. But it seems that the wrapping git repo will keep managing the hash of them in itself, needlessly introducing noise to its own history.

E.g. after an submodule update --remote there will be a change introduced in the wrapping project, something like:

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   <module-name> (new commits)

Is it possibly not to include any hashes or information about the hash of submodules, in a git repo containing submodules, such that submodule update will not introduce the need for new commits and will not be reflected in the project's history?

Motivating Scenario:

This would solve a workflow that can be described as "always use the latest of all submodules", which currently requires special administration after each submodule update (committing or somehow removing the above change record from the history.. which makes workflow very confusing when you just always want to use the latest).

解决方案

Long answer

Is it possibly not to include any hashes or information about the hash of submodules

No, that is the all point of a submodule: to record in the parent repo a fixed SHA1 (that is the gitlink, special entry in the index).

As a convenience, you can update the content of a submodule in order to match a remote branch of the submodule upstream repo.
(git submodule update --remote)

But once that update is done, the result is no different than any other manual modification inside a submodule: its SHA1 change, and needs to be recorded in the parent repo.

The goal is for the parent repo to be cloned later with the exact same content (including its submodules content), hence the submodules are checked out at their respective SHA1 recorded by the parent repo.

---

Commit 9937e65 (Git 2.0, Jan. 2014) mentions:

Make it clear that there is no implicit floating going on; --remote lets you explicitly integrate the upstream branch in your current HEAD (just like running 'git pull' in the submodule).
The only distinction with the current 'git pull' is the config location and setting used for the upstream branch, which is hopefully clear now.

commit 23d25e4 details:

This commit does not change the logic for updates after the initial clone, which will continue to create detached HEADs for checkout-mode updates, and integrate remote work with the local HEAD (detached or not) in other modes.

The motivation for the change is that developers doing local work inside the submodule are likely to select a non-checkout-mode for updates so their local work is integrated with upstream work.
Developers who are not doing local submodule work stick with checkout-mode updates so any apparently local work is blown away during updates.

For example, if upstream rolls back the remote branch or gitlinked commit to an earlier version, the checkout-mode developer wants their old submodule checkout to be rolled back as well, instead of getting a no-op merge/rebase with the rolled-back reference.

TL;DR

Probably nothing in the git universe can make a repo automatically point at the latest of a submodule rather than at a specific commit hash of it. While submodule update --remote can be used as a convention to ignore that tracking, history describing the updates will always be recorded in the parent repo.

这篇关于将子模块更新为最新版本，而不会累积更新历史记录的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！