Since this is not strictly related to the topic of `git switch` I
renamed the thread.
Sergey Organov wrote:
> Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:
> > Sergey Organov wrote:
> >> Overall, if we aim at clear documentation, we need to define our
> >> documentation terms as precise as possible, and then use them
> >> consistently.
> >>
> >> For example:
> >>
> >> "branch": a chain of commits
> >>
> >> "branch tip": the most recent commit in a branch
> >>
> >> "branch name": specific type of symbolic reference pointing to a branch tip
> >
> > Completely agree on all three (although I would call it "branch head",
> > not "branch tip").
>
> I see why "branch head", as you later introduce "branch tail", but a
> branch (of a plant) has no "head" (nor "tail"), right? BTW, how the base
> of a plant branch is called in English, and how one finds "branch tail"
> on a real tree anyway? I mean, there are probably a few of them, at
> every fork. In Git it's even more vague, as a branch could logically
> begin at any place, not necessarily at a fork point.
We don't necessarily need a 1-to-1 mapping with common English (although
that would be nice). Anoher option could be "base" and "tip".
> OTOH, "head" and "tail" are obviously taken from CS "list" concept, and,
> provided "chain" == "list", it does make sense.
I took it from Mercurial, where the tip of a branch is called "head",
and in fact a branch can have multiple heads.
> And then we have 'HEAD' that points to the current branch tip anyway.
It actually points to a branch, or rather references a branch, since it
uses the branch name.
> Dunno, in fact I don't have any preference among "tip" and "head".
I don't either, but from different sources (non-git-specific) I've heard
"head" more often.
> As for branch tail, I do have convention of marking start of a
> long-standing branch with corresponding tag, where branch "foo" has
> corresponding "foo-bp" tag marking its "branch point". Recently I
> started to mark start of feature branch with yet another branch "foo-bp"
> rather than tag, "foo" being set to track "foo-bp", that allows to
> automate rebasing of "foo" against correct base.
So foo-bp is the upstream of foo, and you do basically:
git rebase foo@{upstream}
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.
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.
Another advantage of having this notion is that `git rebase`
automatically updates the tail (in this case to foo@{upstream}).
Cheers.
--
Felipe Contreras
