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

[David Kastrup <dak@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Tue, 18 Nov 2014 16:59:58 -0500
>> From: John Yates <john@yates-sheets.org>
>> Cc: Sergey Organov <sorganov@gmail.com>, Emacs developers <emacs-devel@gnu.org>
>> On Tue, Nov 18, 2014 at 1:18 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> 
>>     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.
>> 
>> Earlier VCS often had more reified branches. A phrase that crops up a
>> lot in git descriptions is "lightweight branching". This was achieved
>> by paring back the branch concept - leaving nothing more than the nodes
>> reachable from a named ref - and by making ref manipulation very common.
>> 
>> When contrasting git to earlier VCS in none of the git intros I have
>> read have I seen that particular point made.
>
> You are again talking about differences in implementation.  "Branch"
> the concept does not change a bit, no matter what VCS are you using.

When "Branch the concept" leads you to conclude "this can't happen" for
things that clearly can, it is of moderate usefulness.

In a Git repository, the branching structure evolves.  The original
branches something was committed on may no longer exist (this is the
rule rather than the exception for user-committed changes "directly" in
master).  In Git, a branch is a throwaway entity, created on a whim,
renamed, moved, merged, rebased on a whim.  In CVS, it was something
really expensive IIRC.

Git has a record of the "real history".  This record is kept in
"reflogs" which are periodically cleaned out, are ephemeral, limited to
local access and tied into one particular repository.  The reflogs are
good for analyzing major oopses and recovering from them.  But they are
not part of the _distributed_ version control.

Reflogs contain the _actual_ history.  In contrast, everything one
shares with others is a deliberate, vetted history.  And that's what on
public and shared record.  This deliberate vetted history does not
include information about what branch some commit originated from.  You
may put something about it in the commit message, but it is not part of
the automatically managed metadata.  Keeping it consistent would be
really hard, and Git does not even try.

Pretending that it must nevertheless be a part of Git's concepts does
not really buy you anything.  You cannot make useful deductions about
Git's behavior based on theories that ascribe magic properties to
branches that have no reflection in the data Git actually stores.

-- 
David Kastrup