Re: Obscure error/warning/information message from git pull

[Alan Mackenzie <acm@muc.de>]

Hello, Sergey.

On Tue, Nov 18, 2014 at 11:57:34PM +0300, Sergey Organov wrote:
> Eli Zaretskii <eliz@gnu.org> writes:

> >> It's the latter that I've tried to help to achieve. Sorry if I
> >> failed.

> > You cannot help people understand new tools if you start by telling
> > them to forget everything they've learned.  You should instead build
> > on what they know, or think they know, gradually replacing that with
> > new knowledge.

> Sorry, but I really think that to better understand Git, one should
> forget, at least temporarily, some things she learned from other VCSes.
> Then after she gets what, say, "branch" means to Git, she can tweak her
> previous knowledge to fit.

You must also admit that git is at fault here for misusing common words.
A "branch" in English is not and cannot mean a "tip of a branch".  Yet
git has twisted the language such that this has become its meaning.  And
any cultured person must suppress his revulsion at such abuse as part of
the cost of learning git.  YUCK!

> > Regardless, the concept of "branch" as a separate line of development
> > is not killed by Git.  It's just that a branch can be named by its
> > tip, and vice versa.

> >> My point is that branch name doesn't represent anything else but
> >> particular reference to particular commit in Git.

> > No, it also represents all the previous commits made on that branch
> > that are reachable through first-parents.

> Well, given the following history (time goes from left to right):

>              - C - D <- foo
>            / 
> ... - A - B
>            \
>              - E - F <- bar


> what branch commit A was made on, 'foo' or 'bar'?

Quite clearly, A was committed on branch foo, since bar didn't exist at
that time.

> You see, you should have had no "made on that branch" in your
> description, provided you describe Gits' idea of a branch, not your one,
> as Git does not remember on what branch commit was made.

Are you saying that at B, when bar is branched from foo, git discards
all information about this branching, remembering only that there are two
branches which are henceforth of fully equal status where before there
was just one?

If this is indeed the case, it is not surprising that git's abstraction
of branching is so broken.

> -- 
> Sergey.

-- 
Alan Mackenzie (Nuremberg, Germany).