我的仓库中有樱桃选择记录为合并。它抛出了git选择的合并基。是否可以指定合并基?如果可以,如何指定?
- 示例 *:f从A处的master分支出来。C被樱桃挑选到f,但被误导为以K和C为父的merge。
A-B-C master
\ \
K---C'-L f
当把f合并到master git中时,会发现C是最佳共同祖先,并将其作为Base。由于Base中包含B,但f中缺少B,因此合并操作会取消。使用A作为Base会给予正确的合并。
编辑:This answer排除了下面问到的B计划。所以,希望有人能回答:如何在git merge中指定合并基数?
编辑,B计划:通过使用tfs-git从两个tfs分支中提取数据,仓库就变成了这样。一个变更集的“Merge selected range”在git中显示为完全合并。另一个解决方案是配置git-tfs不创建合并提交。(停止对所有变更的“cherry-pick”是不可能的。)
3条答案
按热度按时间3xiyfsfu1#
如何在git merge中指定合并基础?
带移植物:
编辑来自注解:对于带注解的标签,在引用的末尾指定
^{}
,tip1^{}
等,让rev-parse追踪并打印提交的id,而不是只满足于标签的id。8ehkhllq2#
我认为问题是“樱桃采摘”(以Git的方式)似乎是no函数或Team Foundation Server版本控制的planned workflow。
git的“cherry-pick”命令应用“[给定]提交在[...]分支顶端引入的更改,并使用这些更改创建一个新的提交”。(http://git-scm.com/docs/git-cherry-pick)
TFSVSC没有“挑选”命令,但可以执行“合并[a]选定范围”或“部分合并”,后者将指定的(后续)变更集合并到不同分支(http://blogs.msdn.com/b/dstfs/archive/2009/05/04/partial-merges-in-tfs-a-guide.aspx)上的新变更集。
这就是
git-tfs
似乎达到极限的地方(在写作的那一刻)-Invalid selective merges instead of cherry picks.(目前)似乎没有故障安全的方法将部分合并转换成相应的git-cherry-pick,其中git-merge会产生错误的结果,这是由于Git基于快照(因此需要依赖树)与TFS基于变更集的差异。目前我认为你必须等到git-tfs的问题得到解决,或者在git-repository中进行挑选。另一种方法是 checkout tfs-repository并将其提交到git-repo,但这将在传输过程中消除提交历史记录。
blmhpbnm3#
作为对jthill回答的补充。
我也遇到过类似的问题,现在 <GIT_DIR>/info/grafts 已经过时,下面是我如何使用
git replace
解决同样的问题: