我对我认为我理解的问题的解决方案略有不同(意译:如何处理比我将称为 bad_leaf 的分支/主干的当前叶更旧的“good_revision”,并将自“good_revision”以来的更改视为坏),这相当于在两个版本之间应用差异,但从/到顺序相反:
使用来自 bad_leaf 的基线而不是默认的最后一次常见提交,合并来自 good_revision 的(空)分支;因此,将应用的差异是原始分支与您创建的 good_revision 分支的差异,因为它不会看到它们已经被应用。使用最新的作为基线“隐藏”那些否则会使它忽略所有更改,因为它们已经应用。
fossil update good_revision
fossil commit --allow-fork --allow-empty
# note the uuid from that commit (for use as forked_basis below)
fossil merge -f --integrate --baseline bad_leaf forked_basis
那么当然曾经快乐过,
fossil commit
它不会创建任何应该称为“错误”的分支,它只是将从 good_revision 到 bad_leaf 的反向差异应用到 bad_leaf 中,让您回到原来的位置,您可以继续提交过去的相同(新)叶子在bad_leaf。
diff
与上述命令匹配后的结帐相比,在原始 good_revision 处结帐的(直接 gnu,不是化石差异)。除了丢失文件的空目录外,fossil 无论如何都不会跟踪/整理死目录。
警告:我使用化石的时间不长,它在几个方面与我习惯使用 cvs/svn/git/hg/perforce/clearcase 的常见方式不同。
添加此答案的原因:我发现现有的答案更难理解,因此不确定我是否相信自己能正确地做到这一点。