Re: What actually is a branch?

Martin wrote:

On 08/07/2021 22:37, Felipe Contreras wrote:

quoted

Technically a branch is a file with an object id in it. That doesn't
give the user any useful information.

What is important is the *meaning* of that file.

quoted

People indeed tend to thing, I branched at X, so anything before is not
part of the branch.
"--contains" says otherwise.

Yes, that is the status quo, but the fact that X is the case doesn't
mean it *should* be the case.

Well yes. So lets start over.

A branch is a container for commits. Those commits have a start (root or 
base / not sure), and an end (head).
The commits are continuous, in that they have no gaps.

The big question is the start point of the branch.

And there is a further consequence:
If a branch "starts" at "base" then
  --contains  needs to be changed
  --reachable needs to be added (for what contains does now)

Indeed, but as of this moment @{base} is not being considered, it's just
a mental model tool.

This also complicates it, because now there are 3 types of relation 
between commits and a branch
- unrelated (outside / not reachable)
- inside (base..head)
- reachable (base and all its parents) // better word needed

I think that has always been the case. The fact that the git
documentation doesn't talk about that doesn't mean the concept doesn't
exist.

The last is important:

A => B => C master
      \ => D  foo

If I delete master, without the concept of reachable, I would expect 
commit A to be dropped. Technically B should drop too, but it takes some 
insight to expect that.
So then with only the branch foo left, I would also have only the commit 
D (well maybe B too, if the system is lenient)

Commits don't need a branch to exist. B could have a tag 0.3.7 and no
branch pointing to it. There could be other refs pointing to that
commit.

One might even go an say if master is deleted, then the base of foo is 
deleted. since foo must have a base, and it no longer has, foo can not 
exist any longer.

Of course it can. The base of a branch doesn't necessarily need to be
part of any other branch.

Or another way to think of it is that B is part of an unnamed branch.

quoted

A branch that you hold, or point to, is a concete concept easy to
underand. When I say: "me, my sister, and my father are one tiny branch
of the Contreras family", people understand what that means inuitively.

On the other hand saying "Felipe contains his great-great-grandfather"
would stop anyone on their tracks.

The Chicago branch of your family contains Al Capone.
That works.

Sure, if you start from a certain grandparent, not if you start from my
grandfather.

Most humans have issue with more than 7 items. A branch containing
millions of members reaching as far back as a fish is a notion an
evolutionary biologist might not have any problem with, but most people
would struggle.

For most people a branch must start from somewhere.

quoted

But if you do `git reset --hard origin/master`, you are saying: drop
everything about this branch, and make it the same 'origin/master'.
*Now* we have a reason to distinguish `git merge --ff-only` from `git
reset --hard`.

No you don't. IMHO not.
"reset --hard" resets the branch to a commit. You can specify that 
commit by giving a branch-name (that then will be resolved). But it 
could be any commit, even a detached one.

OK. Sure. It could be repurposed to say what I explained, but we might
be overloading that command in that case.

How about `gt branch --reset <otherbranch>`?

So "reset --hard" has to set the base and the head to the same commit. 
Effectively creating an empty branch based at that commit.

Maybe. Or maybe the base remains the same. Fortunately that's not
something we need concern ourselves with at this moment.

But local tracking branches still are counter intuitive.

IMHO local tracking branches should follow one of the following 
scenarios. (And ideally that should be the same for all local tracking 
branches, for any user.)

1) Always have the same base as their remote branch.
Therefore always have the same content as the remote branch, up to where 
they diverge, if they diverge.

2) Not include the remote branches content. Just hold my local commits, 
until they will be pushed to the remote.

But neither works:

Say I have a local commit, and you pushed new changes to the remote.
    git pull --rebase
My branch is rebased.
So my local tracking branch has its base at the head of the remote. It 
has only local commits => case 1.

Say I have no local commits, and you pushed new changes to the remote.
    git pull --ff-only
If I understand correct the --ff-only move the head of my local branch, 
but leaves the base where it is.
Now I have some shared commits with the remote branch.
=> either case 2, or worse none of the 2 cases.

There's no need for --ff-only, do `git pull --rebase` on both cases, and
the base will constantly be reset to the remote head.

However, at least I never do this. My 'master' branch doesn't contain
any commits and I always do the equivalent of `git pull --ff-only`, so
the base would never change.

quoted

If you send a pull request for your 'master' branch, which then gets
merged to 'origin/master', then you can do `git merge --ff-only` to
advance the head pointer of the 'master' branch to the remote branch so
both are in sync... Except the base won't be the same.

There may be something I missed. ff should not touch the base?
So the 2 base will still be the same or not the same, depending on if 
they were equal before the ff?

That's right. Before the fast-forward the base was different (because of
the rebase), so after the fast-forward the base remains different.

quoted

quoted

So yes, what is a branch? More exactly what does it contain.
Two examples, that to me suggest two answers.

Not necessarily. See above.

I feel we must have some understandingly on the part how base and local 
branches would interact.

You agree: rebase changes the base (it creates a new branch on to --onto)

You pointed out there also is fast-forward. But see my above example.
I am not even doing a pull request. I simply go for you and I both can 
push to the same remote. So we both commit to master and pull/push it.

It doesn't matter who does the merge:

  git merge origin/master
  git push

It would be the same as a pull request followed by a fast-forward
(except with the parents reversed).

The base remains unmoved.

quoted

quoted

Also if branch@{base}..branch  then there is a problem.
- branch@{base} is then correctly not part of the branch
- So immediately after "git switch -c branch" the branch is empty => ok
But if so, then what is the branch head at that time?
The Pointer would point the @{base}, but @base is outside the branch. So
the pointer of the branch points outside the branch?

Yes, the base pointer doesn't include the branch. When you do
`branch@{base}..branch` that's the same as `^branch@{base} branch` so that
excludes all the commits rechable from branch@{base} *including* that
commit iself.

My question is, where you see the branch head pointing to?
If the branch is empty, i.e. if it has no commit at all, then to what 
commit does the branch head point?

To the same commit as the base: master..master contains zero commits.

quoted

quoted

The only problem is:
branch is too often used for "the commits contained in the branch". That
is way to common to even try to stop it.

We don't need to stop it, we can sidestep it.

Instead of talking about the branch, talk about the branch head:
"the brach head is moved to X".

Yes well, we need to be very concise, if we speak about anything that is 
not the "commits in the branch".

quoted

quoted

quoted

When you change the branch head you are effectively changing the branch.

Well if branch is the pointer, then you change the branch, and head is
being changed.
If branch is the content, then you change the head, and yes the content
changes.

Exactly, so regardless of which semantics you choose, everyone
understands that the branch is not the same anymore.

Your original text was

quoted

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?

And yes, if either boundary changes, the branch changed.

But our immediate concern is to improve the documentation of
`git switch -C`, and perhaps improve the interface while we are at it.

I believe we have all the semantic tools needed to write something that
is understandable by most people regardless of their conception of what a
branch is.

No?

-- 
Felipe Contreras