Re: What actually is a branch?

[Felipe Contreras <felipe.contreras@gmail.com>]

Martin wrote:
> On 08/07/2021 00:07, Sergey Organov wrote:
> > Felipe Contreras <felipe.contreras@gmail.com> writes:
> >>
> >> This is works if your base (or tail, or whatever) is static, but many
> >> branches jump around, and that's where @{tail} comes in handy.
> > 
> > Yeah, I see. When I need to make a branch jump around, I do need to
> > manually move my references, but that's fortunately very rare use-case
> > for me. Having direct support for that is still a win.
> > 
> >>
> >> You can do this:
> >>
> >>    git rebase --onto foo@{upstream} foo@{tail}
> >>
> >> This will always rebase the right commits (no need to look into the
> >> reflog). So you can say that the branch is foo@{tail}..foo.
> > 
> 
> Maybe I am missing something, is tail for tracking branches only, or for 
> just any branch?

Any branch.

> If for any branch, looking at
> 
>    A => B => C => D  master
>         |
>          \          / => G => H  branch_1
>           => E => F
>                     \ => I => J  branch_2
> 
> Where is the base of branch_1 and branch_2?

It depends where the corresponding `git switch --create` command was
issued.

If you did `git switch --create branch_1 B`, then @{tail} is B.
If you did `git switch --create branch_1 F`, then @{tail} is F.

> (and does it matter if they have an upstream)

No. That's completely independent.

> Maybe branch_1 diverged from Master, and then branch_2 from branch_1?
> 
> Maybe the other way round.
> 
> Maybe there was a branch_0 (that got removed),
> and branch_0 diverged from master, and branch_1 and branch_2 both from 
> branch_0?

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.

> ---
> Also base may be misleading.
> 
> If head is the one end of the commit chains, then base should be the other.
> But all branches contain commits A (and B). So the base would be A.

All branches contain A, but only one branch could have A as a
base/tail (under normal operations), and likely none do.

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.

As both branches move forward they diverge, and the "fork-point" is B,
but B is not the tail of *any* branch.

Naturally then branch_1 would be created with F as a starting point, so
that would be the tail of branch_1.

And once again, even though F is part of both branch_1 and branch_2,
it's the tail of branch_1 *only*.


This is a convoluted way of saying: the tail of a branch is the point
where that branch was created.

> "fork" would be more descriptive IMHO?

As you can see from the example above, the tail doesn't necessarily have
to be a fork-point.

Not to mention that there can be multiple forks after the tail (e.g. B
and F).

> Also, if that is to save the user from looking up fork points, maybe 
> extend the syntax
>    branch_1@{fork:branch_2}
>    branch_1@{fork:master}
> 
> Depending on some of the answers to the above
>    branch_1@{fork}
> nearest fork, or upstream fork?

Except it's not necessarily a fork, nor the nearest, nor related to
upstream...

So it's not a fork.

It can be literally any commit.

Cheers.

-- 
Felipe Contreras