Martin wrote:
> On 08/07/2021 00:07, Sergey Organov wrote:
> > Felipe Contreras <felipe.contreras@xxxxxxxxx> 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
