Re: What actually is a branch?

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