Re: What actually is a branch?

Martin wrote:

On 08/07/2021 00:07, Sergey Organov wrote:

quoted

Felipe Contreras [off-list ref] writes:

quoted

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.

quoted

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