Re: What actually is a branch?

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Jul 8, 2021, 17:33 UTC
Message-ID: <60e736e72da68_30939020850@natae.notmuch>
In-Reply-To: <4057b3ac-a77c-0d5f-d3f4-ad781754aae4@mfriebe.de>

Martin wrote:

Show 27 quoted lines

> 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.

I'm not really proposing such feature at this point. I did it on 2013 just to have a solution to this problem, but I didn't push for it back then.

If I ever work on that feature again I will consider the name "base", sure, but the only reason I mentioned this @{tail} concept is to try to define in a more accurate way what a branch actually is.

Show 19 quoted lines

>  > 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>.

Yes and no. <upstream> is where branch is rebased *to*, not where it's rebased *from*:

  git rebase --onto foo@{upstream} foo@{base} foo

This command rebases all the commits foo@{base}..foo on top of foo@{upstream}.

Another way to think of it is that you'll cherry-pick foo@{base}..foo on top of foo@{upstream}.

Show 13 quoted lines

> 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)

Yes, A is the new base.

Show 5 quoted lines

>     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 new base is E.

It's not complicated, the base is whatever --onto is.

Show 20 quoted lines

> 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
>

I did not code that, but it's something people probably would need at some point. I would do `git branch --set-base` though.

Anyway, it seems I wasn't very clear, I'm not really proposing this feature. Although I think it's something that git is missing, it would be a pain in the ass to attempt to get it merged, I have much more important features I want to get done, and those don't have much chance of being merged either.

The only reason I mentioned @{tail} (or @{base}) is to have a better mental model of what a branch is.

 1. A branch is whatever is inside `branch@{base}..branch`
 2. `branch` is the branch head (`branch@{head}`), but it's not the
    branch itself

For all intents and purposes on the git documentation the branch, the branch name, and the branch head are used interchangeably, but semantically speaking they are not the same thing.

When you change the branch head you are effectively changing the branch. If @{base} existed, then changing the base would also change the branch (although that would be a much less dangerous operation).

Does that make sense?

-- 
Felipe Contreras