On 08/07/2021 05:39, Felipe Contreras wrote:
Yeap, the tails of branch_1 and branch_2 could be literally anywhere.
That information is not recoverable from the current data structures of
git, thus the proposal to add a new one.
Ok, thanks for the all the explanation.
A word on the name "tail". IMHO really confusing. I get where it is
coming from.
But a lot of people will know head and tail utilities from their shell.
And "tail" is the one that shows lines on the end of the file to which
new data is added. Which is "head" in git.
Also a tail is something that follows, but (except for rebase), the base
point is fixed.
I think (despite my earlier comment) "base" is a better word.
It also goes along with "git rebase" which acts on the "base".
However wording around that topic probably still needs to be very careful.
"base" must be clearly distinguished from "start". Because "start" might
imply that only commits from here on forward are contained, but that
contradicts --contains which reports root to head.
> Suppose branch_2 was created this way:
>
> git switch --create branch_2 A
>
> Then commit B was created under branch_2. Then master was fast-forwarded
> to branch_2, so you have:
>
> A => B master
> ^ ^
> tail/branch_2 -+ +- head/branch_2
>
> Both branches have A, but only branch_2 has A as tail.
So base (tail) is the shared commit "A" on which branch_2 was created.
(rather than the first commit made in branch_2 which is "B")
I can see how that is needed for "git rebase" so @{base} can be used for
<upstream>.
What happens if branch_2 is rebased?
Will the base be set to the commit onto which the branch was rebased?
A => B => C => D => E master
\ => F => G foo (base = B)
foo was created on B, then fast forwarded to C, then diverged.
git rebase --onto A foo@{base} foo
Now that foo diverges before B, having B as base for foo seems odd.
(Also A will have C' as child, So the base really is A now)
git rebase --onto E foo@{base} foo
In this case C is already contained in master, so it will be skipped.
If the base is moved, then foo@{base}..foo will no longer contain C.
IMHO that is correct, because rebase skipped it.
The alternative if base = C would be kept, then foo@{base}..foo would
contain D and E. And that seems wrong?
Will there be a way to manually repoint the base?
A => B => C => D master
\ => E => F foo
\ => G => H bar (base = F)
If I do
git rebase --onto master bar@{base} bar
then the commits E and F will not be part of the rebase.
That is fine. I must handle them before.
But if I deleted foo (or for other reasons decide E and F should be
handled if I rebase bar) can I make them to be included?
Something like
git base --repoint B bar
