From: Felipe Contreras <felipe.contreras@gmail.com>
To: Martin <git@mfriebe.de>,
Felipe Contreras <felipe.contreras@gmail.com>,
Sergey Organov <sorganov@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: What actually is a branch?
Date: Thu, 08 Jul 2021 19:45:37 -0500 [thread overview]
Message-ID: <60e79c31aaa72_30b8a4208c1@natae.notmuch> (raw)
In-Reply-To: <2b85a7eb-d0be-65e7-ecbb-1750abf53e53@mfriebe.de>
Martin wrote:
> On 08/07/2021 22:37, Felipe Contreras wrote:
> > 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.
> >
> >> 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.
> > 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.
> > 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.
> > 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.
> >> 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.
> >> 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.
> >> 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".
>
>
> >>> 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
> > 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
next prev parent reply other threads:[~2021-07-09 0:45 UTC|newest]
Thread overview: 103+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-29 15:28 PATCH: improve git switch documentation Martin
2021-06-29 16:35 ` Junio C Hamano
2021-06-29 19:04 ` Martin
2021-06-29 22:39 ` Junio C Hamano
2021-06-30 8:50 ` Martin
2021-06-30 22:59 ` Junio C Hamano
2021-07-01 10:06 ` Martin
2021-07-01 11:27 ` Sergey Organov
2021-07-07 18:34 ` Felipe Contreras
2021-07-07 20:46 ` Sergey Organov
2021-07-07 21:25 ` What actually is a branch? Felipe Contreras
2021-07-07 22:07 ` Sergey Organov
2021-07-07 22:35 ` Martin
2021-07-08 3:39 ` Felipe Contreras
2021-07-08 10:15 ` Martin
2021-07-08 17:33 ` Felipe Contreras
2021-07-08 19:21 ` Martin
2021-07-08 20:37 ` Felipe Contreras
2021-07-08 23:11 ` Martin
2021-07-09 0:45 ` Felipe Contreras [this message]
2021-07-09 13:24 ` Martin
2021-07-09 15:08 ` Felipe Contreras
2021-07-09 15:23 ` switch requires --detach [[Re: What actually is a branch]] Martin
2021-07-09 16:21 ` Felipe Contreras
2021-07-09 16:38 ` Randall S. Becker
2021-07-09 17:10 ` Felipe Contreras
2021-07-09 16:54 ` Martin
2021-07-10 10:08 ` Sergey Organov
2021-07-10 19:18 ` Felipe Contreras
2021-07-09 14:29 ` PATCH: improve git switch documentation Martin
2021-07-09 16:10 ` Felipe Contreras
2021-07-09 16:51 ` Martin
2021-07-09 17:41 ` Felipe Contreras
2021-07-09 18:23 ` Martin
2021-07-10 19:45 ` Felipe Contreras
2021-07-10 20:07 ` Martin
2021-07-10 20:49 ` Felipe Contreras
2021-07-10 22:13 ` Martin
2021-07-10 23:35 ` Felipe Contreras
2021-07-11 9:10 ` Martin
2021-07-11 9:30 ` Sergey Organov
2021-07-12 16:28 ` Felipe Contreras
2021-07-12 16:33 ` Martin
2021-07-12 16:58 ` Felipe Contreras
2021-07-12 17:52 ` Martin
2021-07-12 19:08 ` Felipe Contreras
[not found] ` <3a84e4c9-4e48-1cbe-4fe6-150ff56c8508@mfriebe.de>
[not found] ` <60ecbe577a086_a6b702082@natae.notmuch>
2021-07-13 10:42 ` Martin
2021-07-13 16:02 ` Felipe Contreras
2021-07-16 18:12 ` Martin
2021-07-16 18:31 ` Martin
2021-07-16 18:56 ` Felipe Contreras
2021-07-17 7:02 ` Martin
[not found] ` <1997ca3b-117a-e19a-0dee-7342a2f1a0e7@mfriebe.de>
[not found] ` <60f1f4c3dd8b1_14cb208c1@natae.notmuch>
[not found] ` <fedbfe1f-9e6d-f46f-ca41-e176a30e938c@mfriebe.de>
[not found] ` <60f22aaa6a4f1_1f602081b@natae.notmuch>
2021-07-17 10:07 ` Martin
[not found] ` <60f33f8a7c39b_507220823@natae.notmuch>
2021-07-17 21:23 ` Martin
2021-07-19 17:51 ` Felipe Contreras
2021-07-11 7:57 ` Sergey Organov
2021-07-11 9:27 ` Martin
2021-07-11 9:37 ` Sergey Organov
2021-07-11 10:24 ` Martin
2021-07-12 16:34 ` Felipe Contreras
2021-07-10 22:13 ` Naming the --forec option [[Re: PATCH: improve git switch documentation]] Martin
2021-07-10 23:18 ` Felipe Contreras
2021-07-11 0:39 ` Martin
2021-07-12 16:15 ` Felipe Contreras
2021-07-10 10:24 ` PATCH: improve git switch documentation Sergey Organov
2021-07-10 10:37 ` Bagas Sanjaya
2021-07-10 11:05 ` Martin
2021-07-10 16:32 ` Sergey Organov
2021-07-10 20:12 ` Felipe Contreras
2021-07-11 9:04 ` Sergey Organov
2021-07-11 10:05 ` Martin
2021-07-11 12:23 ` Sergey Organov
2021-07-11 13:39 ` Martin
2021-07-11 14:49 ` Sergey Organov
2021-07-11 16:51 ` Sergey Organov
2021-07-12 10:31 ` Kerry, Richard
2021-07-12 11:11 ` Sergey Organov
2021-07-12 16:55 ` Felipe Contreras
2021-07-12 16:24 ` Felipe Contreras
2021-07-12 16:39 ` Martin
2021-07-12 17:09 ` Felipe Contreras
2021-07-12 22:58 ` Sergey Organov
2021-07-12 23:36 ` Felipe Contreras
2021-07-13 11:20 ` Martin
2021-07-10 20:00 ` Felipe Contreras
2021-07-10 19:51 ` Felipe Contreras
2021-07-11 9:52 ` Sergey Organov
2021-07-12 16:44 ` Felipe Contreras
2021-07-13 10:57 ` Sergey Organov
2021-07-13 16:10 ` Felipe Contreras
2021-07-14 19:14 ` Sergey Organov
2021-07-14 19:51 ` Felipe Contreras
2021-07-14 20:42 ` Sergey Organov
2021-07-08 3:12 ` What actually is a branch? Felipe Contreras
2021-07-08 11:16 ` Sergey Organov
2021-07-08 18:05 ` Felipe Contreras
2021-07-01 14:58 ` PATCH: improve git switch documentation Junio C Hamano
2021-07-01 17:29 ` Martin
2021-07-01 17:46 ` Sergey Organov
2021-07-07 18:54 ` Felipe Contreras
2021-07-07 18:47 ` Felipe Contreras
2021-07-07 18:14 ` Felipe Contreras
2021-07-01 0:06 ` Matt Rogers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=60e79c31aaa72_30b8a4208c1@natae.notmuch \
--to=felipe.contreras@gmail.com \
--cc=git@mfriebe.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=sorganov@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).