我有一个包含子模块foo的项目main.对于这个特定的项目,我想对foo做一个小改动,只适用于这个特定的项目main.
main/
+ .git
+ main.c
+ lib/
| + bar.c
+ foo/ # My `foo` submodule
+ .git
+ config.h # The file I want to patch from `main`
+ ...
一个常见的解决方案是转到我的子模块,在一个名为main-project的新分支上为main做一个提交应用补丁,然后推送它.不幸的是,这是一个非常糟糕的方法,因为我正在改变foo,这对主要问题很重要.此外,当我将foo更新到最新版本时,我将不得不挑选补丁,这在foo的历史中引入了很多噪音.
另一个解决方案是在main上有一个真正的补丁文件,它在构建之前应用于foo.不幸的是,由于这会修改子模块内容,并且我将在foo上进行未提交更改,因此它也不是一个好的解决方案.
理想的解决方案是使用Git跟踪我的补丁,但是在顶层(例如直接在main上,而不是在foo上).从理论上讲,可以在Git树上添加一个指向子模块位置的blob:
blob <sha> main.c
tree <sha> lib/
commit <sha> foo
blob <sha> foo/config.h
有了这个想法,属于foo的修补文件config.h将在main上被跟踪.
怎么可能这样做呢?
最佳答案 我仍然会选择第二个选项(在main上有一个真正的补丁文件),但我的构建过程适应:
>在子模块中制作config.h的副本
>应用补丁
>构建
>将config.h恢复为其原始内容.
这样,我保持子模块状态不变.
OP在评论中添加:
But your solution is not working in a IDE, Intellisense will be confused –
是的:为此,我会在结帐时自动应用补丁,并在检查时通过smudge/clean content filter driver将其删除.
这样,补丁在整个会话期间保持不变,但在任何git status / diff / checkin上都会消失.
虽然这并不理想,并且似乎没有一种原生的Git方法来处理这个问题.