如何删除子模块,但保留其历史记录(与父历史记录链接)? [英] How to remove a submodule going forward, but keep its history (as linked from parent history)?

查看:120
本文介绍了如何删除子模块,但保留其历史记录(与父历史记录链接)?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

说我有一个项目,该项目具有使用git submodule实现的依赖项.现在,我正在进行更改,不再需要这种依赖关系.我要提交如下更改:

  • 如果有人签出此提交或任何后代,则子模块不存在.
  • 但是,如果有人签出了较旧的提交,或者另一个分支上的提交未与该分支合并,则子模块会重新出现,就像被删除的文件一样.
  • 必须保留子模块自己的git数据库(.git/modules/path/to/submodule),因为它可能包含未推送到远程的提交.

换句话说,我确实要按照如何做的回答消除子模块我要删除一个子模块吗?.实际上,我写这个问题是为了澄清这个问题.[1]

我有空的时候会尝试一些实验.它可能很简单,例如git submodule deinit和/或从.gitsubmodules中删除其条目.我搜索了Stack Overflow,没有发现专门针对这种情况的问题或答案.即使是精湛的掌握Git子模块也不清楚. >


[1]:这些答案所需的许多步骤告诉我,这种消除不是正常"的,否则git将包括为您完成所有操作的瓷器命令.相反,git deinit具有非常狭窄的行为.我认为这是故意的.

解决方案

我在2013年记录的 git submodule deinit 及其关联的rm -rf .git/modules/a/submodule都假定已推送了删除的子模块.

最初引入子模块是为了将其用作只读对象,以便将其他存储库内容添加到存储库中,而不必进行修改.
与子树不同,在子树中更自然地期望进行修改.

话虽这么说,是的,如果您在未提交/推动该子模块的本地更改的情况下删除了一个子模块,那么最终结果将不会令人满意.

一个可能的补丁想法是,当检测到子模块当前HEAD与自身内部的远程跟踪分支(例如其自身的origin/master)不匹配时,阻止/失败git submodule deinit命令

Say I have a project that has a dependency implemented using git submodule. Now I'm making a change where this dependency is no longer needed. I want to commit a change that works as follows:

  • If anyone checks out this commit or any descendants, the submodule doesn't exist.
  • But if anyone checks out an older commit, or a commit on another branch not merged with this one, the submodule reappears, just as a deleted file would.
  • The submodule's own git database (.git/modules/path/to/submodule) must be preserved as it may contain commits not pushed to a remote.

In other words, I do NOT want to obliterate the submodule as directed by the answers to How do I remove a submodule?. In fact I wrote this question as a counterpoint to clarify that one.[1]

When I get some time I will try some experiments. It may be as simple as git submodule deinit and/or removing its entry from .gitsubmodules. I searched Stack Overflow and found no questions or answers addressing this case specifically. Even the superbly written Mastering Git submodules is not clear about this.


[1]: The many steps required in those answers tells me that such obliteration is not "normal", otherwise git would include a porcelain command that did it all for you. Instead git deinit is provided with very narrow behavior. I think it very intentional.

解决方案

The git submodule deinit that I documented in 2013 and its associated rm -rf .git/modules/a/submodule both assume the removed submodule was already pushed.

Submodules were initially introduced to be used as read-only, in order to get other repository content into your repository, without necessarily the intent of modifying them.
This differs from subtree, where modifications are more naturally expected.

That being said, yes, if you remove a submodule while having not committed/pushed local changes to said submodule, the end result won't be satisfactory.

A possible patch idea would be to block/fail the git submodule deinit command when it detects that the submodule current HEAD does not match its own internal remote tracking branch (its own origin/master for instance)

这篇关于如何删除子模块,但保留其历史记录(与父历史记录链接)?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆