From: Junio C Hamano <firstname.lastname@example.org>
To: Sergey Organov <email@example.com>
Subject: Re: [PATCH] glossary: improve "branch" definition
Date: Mon, 23 Nov 2020 15:26:43 -0800 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
In-Reply-To: <email@example.com> (Sergey Organov's message of "Tue, 24 Nov 2020 02:01:24 +0300")
Sergey Organov <firstname.lastname@example.org> writes:
>> But do we need to say "a separate line of development", instead of
>> just "a line of development"? What is "a line of development" that
>> is not separate? What extra pieces of information are we trying to
>> convey by having the word "separate" there?
> I think it tries to convey a notion that 2 branches represent separate
> lines of development. I.e., that the whole purpose of branching is to
> provide support for independent, or parallel, or /separate/ lines of
So in the context of talking about a branch, there is no need to say
"a separate line". It only starts making sense to use the word
"separate" whey you say "this is a line of development. By the way,
there is another line of development that is separate from the first
> I'm not going to insist on the exact wording though, -- just wanted to
> bring attention to the issue, and "separate" was somehow the first word
> that came to mind when I edited the text.
> As an after-thought, I'd probably add that branch in Git is represented
> by a chain of commits, and then I'd refer to most recent commit of the
> chain, instead of most recent commit on the branch. That'd make
> definition more formal and precise. Makes sense?
It brings up a more serious issue, though.
The only thing everybody can agree on in the above history is that
commit 'x' is at the tip of the branch A, and commit 'y' is at the
tip of the branch B, and 'y^' is on the branch B. There is no good
answer to questions like
where does branch 'A' begin?
where does branch 'B' begin?
Perhaps the merge to 'B' was from another branch that no longer
exists (because the whole 4-commit chain was merged at that point to
the integration branch 'B'), and 'A' was forked from that branch
whose name was forgotten.
Any commit in the history represents a line of development behind
that commit, and whether a commit is pointed at by a ref does not
change that. And development is not even a line when you include
forking and merging.
In the mental model of Git about branches, I think the only one
thing people can agree on is that a branch points at a commit, and
checking it out and making a commit on top of it will change that
branch to point at the newly created commit. And this view supports
the word "separate"---whether you have two branches pointing at the
same commit or a different one, building a new commit on and
advancing the tip of one branch does not affect the other branch.
Come to think of it, the original "active" may not have been so bad
a word to begin with. It is misleading in the sense that "active"
used in the original statement does not mean "currently checked
out", but if we read it as "potentially active---can grow in its own
direction", it does convey that each branch can (although does not
have to) represent its own line of development.
So, I dunno. I'd say just settling on the simplest "is a line of
development" would be the easiest path for now.
next prev parent reply other threads:[~2020-11-23 23:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-23 20:05 Sergey Organov
2020-11-23 22:34 ` Junio C Hamano
2020-11-23 23:01 ` Sergey Organov
2020-11-23 23:26 ` Junio C Hamano [this message]
2020-11-24 22:02 ` Sergey Organov
2020-12-02 11:50 ` Sergey Organov
2020-12-02 22:55 ` Junio C Hamano
2020-12-03 13:51 ` Sergey Organov
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:
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 \
* 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 inbox:
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).