使用fork-point在git中进行修订选择 [英] Revision selection in git using fork-point

问题描述

假设我说的是 A..B .来自

我的问题是，当我们说 git rebase --fork-point A B 使用fork-point来评估 A..B 时，这不是吗?如果甚至合并基础都不会影响 A..B 的选择，那么如何将fork-point用于它呢?

---

对于那些想要在本地提交图以上的人，请运行此脚本

 #！/bin/bashgit init.回声"10">>1.txt&&git添加&&git commit -m"1"#将2次提交提交给master回声"3">>1.txt&&git commit -am"m3"回声"2">>1.txt&&git commit -am"m2"#checkout主题分支git checkout -b主题HEAD〜2回声"1">>1.txt&&git commit -am"t1"回声"2">>1.txt&&git commit -am"t2"回声"1">>1.txt&&git commit -am"t3"回声"2">>1.txt&&git commit -am"t4"#checkout small_topicgit checkout -b small_topic1 HEAD〜2回声"1">>1.txt&&git commit -am"s1"回声"2">>1.txt&&git commit -am"s2"git checkout主题git merge small_topic1回声"1">>1.txt&&git commit -am"t5"回声"2">>1.txt&&git commit -am"t6"git分支-D small_topic1#显示图表git log --oneline --all --decorate --graph 

解决方案

^ A 说〜目前没有可从 A 〜访问的提交.

A..B 是语法糖，将其重写为 ^ AB ，因此它可以提交当前从 B 可以访问的内容，除了当前无法从 A 〜.

访问.

-fork-point 有效地说:遍历reflog，并使用排除的refname排除所有 可以到达的提交".

请记住，Git的存在是为了对一个简单的结构做有用的事情:一堆快照.-fork-point 是某人想起的名字，他们~~~~~~~~~~~~~~~~~~~~~~~~~~~为此，我在所有旧提示中浏览了reflog和snip-snip-snip〜.

我的问题是，当我们说 git rebase --fork-point AB 使用fork-point来评估 A..B 时，这不是吗?>

为什么?带有这些参数的叉点表示〜 A..B ，并在任何历史 A 提示处截断〜.那不是你想要的吗?

---

A..B显然没有考虑基于合并的基础(上图中为7bc86ff).

那是不对的，因为

因为如果我们将A..B定义为-A和B的合并基础中B的所有提交，那么此定义将不会给出以上答案.

这不是考虑合并基础的唯一方法.在一个非常简单的基础具体现实之上，您要进行太多的表征和抽象处理:一堆快照.从定义上讲，两个技巧的合并基础都是可以达到的，因此 ^ A B 绝对可以考虑合并基础.甚至两次.

Suppose I say A..B. From here

The most common range specification is the double-dot syntax. This basically asks Git to resolve a range of commits that are reachable from one commit but aren’t reachable from another.

Let us say, a graph like this:

* c6ddc03 (HEAD -> topic) t6
* 11751b7 t5
*   a1c4ed2 Merge branch 'small_topic1' into topic
|\  
| * 7bc86ff s2
| * e1b1384 s1
* | 9582f60 t4
* | 815137a t3
|/  
* 648741c t2
* cfce615 t1
| * 7e46c48 (master) m2
| * 84a4dc7 m3
|/  
* 2d15aa1 1

If I say what is 7bc86ff..c6ddc03 , then I get

c6ddc037e9e67647ae69e213c0c5b8a29f5d2745
11751b72f943c4daeb9f28a8dddd93a4b98cb8dc
a1c4ed284557cde1e1474bc5e3f7ef0cd7008ba8
9582f60bf9e5464254a51cb6a085d41005f5795f
815137ac9cbe51768cdaf4c27200f51ecad27fbb

Clearly, this tells us that A..B does not take merge-base (which is 7bc86ff in figure above) into consideration. Because if we had defined A..B as - All commits of B from merge-base of A and B , then this definition wont give above answer.

My question is when we say git rebase --fork-point A B uses fork-point to evaluate A..B, then is not it wrong ? When even merge-base does not effect A..B selection , how can fork-point be used for it ?

---

For those who want above commit graph in local, run this script

#!/bin/bash

git init .
echo "10" >> 1.txt && git add . && git commit -m "1"

# Add 2 commits to master
echo "3" >> 1.txt && git commit -am "m3"
echo "2" >> 1.txt && git commit -am "m2"


#checkout topic branch
git checkout -b topic HEAD~2
echo "1" >> 1.txt && git commit -am "t1"
echo "2" >> 1.txt && git commit -am "t2"
echo "1" >> 1.txt && git commit -am "t3"
echo "2" >> 1.txt && git commit -am "t4"


#checkout small_topic
git checkout -b small_topic1 HEAD~2
echo "1" >> 1.txt && git commit -am "s1"
echo "2" >> 1.txt && git commit -am "s2"

git checkout topic
git merge small_topic1
echo "1" >> 1.txt && git commit -am "t5"
echo "2" >> 1.txt && git commit -am "t6"

git branch -D small_topic1

#Show graph
git log --oneline --all --decorate --graph

解决方案

^A says ~no commits currently reachable from A~.

A..B is syntax sugar for, gets rewritten as, ^A B, so it's ~commits currently reachable from B, except nothing currently reachable from A~.

--fork-point effectively says "hunt through the reflogs and exclude all commits that were ever reachable using excluded refnames".

Keep in mind that Git exists to do useful things to a simple structure: a dag of snapshots. --fork-point was the name someone came up with for ~they rebased the upstream branch, I want to rebase just my stuff onto the new tip, not the stuff upstream used to refer to but abandoned, so to do that I hunt through the reflogs and snip-snip-snip at all the old tips~.

My question is when we say git rebase --fork-point A B uses fork-point to evaluate A..B, then is not it wrong ?

Why? Fork-point with those args means ~A..B and additionally truncate at any historical A tip~. Is that not what you want?

---

Clearly [...] A..B does not take merge-base (which is 7bc86ff in figure above) into consideration.

That is not true, because

Because if we had defined A..B as - All commits of B from merge-base of A and B , then this definition wont give above answer.

That's not the only way to take the merge base into consideration. You're layering far too much characterization and abstraction on top of a very simple underlying concrete reality: a dag of snapshots. The merge base of two tips is by definition reachable from both, so ^A B most definitely does consider the merge base. Twice, even.

这篇关于使用fork-point在git中进行修订选择的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！