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

["Stephen J. Turnbull" <stephen@xemacs.org>]

Eli Zaretskii writes:

 > > Branches are ephemeral, the commit graph is static.  Equating the two
 > > will not do your understanding favors.
 > 
 > Didn't expect to hear this from you.  Others, yes, but not you.

David tends to be overly emphatic.

In this thread AIUI we're trying to help existing Emacs developers who
find git to be new and confusing.  Eli is proposing that *they* adopt
the abstraction of "branch" as being

    a structure defined by transitive closure of the parent relation
    that "really exists" in the DAG, *with* a "branch ref" as a
    (possibly mutable) name that is an *essential* "handle" to the
    branch for operations such as commit and merge.

I think it's reasonable to say that for the purposes of these
developers, that is useful and unlikely to cause them any harm.

During the transition period (broadly speaking; I wouldn't be
surprised if people are still digging patches out of dormant bzr
branches in late 2016!), it is highly unlikely that they will
encounter any behaviors in the public Emacs repos (renamed branches,
branches that have a social identity with a different extent from
master..branch in the DAG, etc) that violate the "branch ref +
reachable commits" model.  This isn't as restrictive a model as the
one Alan Mackenzie has in mind, with branch as an actual queryable
object with persistent identity and metadata.  The branch-is-object
model is clearly wrong in git.

In other words, branches are implemented in a way that makes them
ephemeral in principle, but you won't need to notice that in Emacs
practice (and Eli advocates ignoring that fact).

On the other hand, the ephemerality of branches is one of the
principal sources of power in git.  I agree entirely with David that
confusing the DAG of commits with a collection of branches means you
lose a lot of the benefits of git, and makes it very hard to use git
as effectively as you used branch-oriented VCSes.