Re: git pull fails with merge conflicts. How can this possibly happen?

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <address@hidden>
> Cc: Yuri Khan <address@hidden>,
>     address@hidden,
>     address@hidden,
>     address@hidden
> Date: Sat, 15 Nov 2014 18:20:29 +0900
> 
>  > Mind you, I come from the same population of the confused whom you are
>  > trying to teach here: my mind still doesn't wrap itself easily around
>  > Git semantics,
> 
> This "confusion" I still don't get.  Git semantics are singly-linked
> list semantics:

I think we have different notions of "semantics", see below.

>                 commit ~ cons (object), tree ~ array of tree-or-blob,
> blob ~ atom, ref ~ list-valued symbol, branch = ref where the commit
> command has push (cl-macro) semantics, tag = ref where the commit
> command has cons (primitive function) semantics.  Everything else
> follows from list-traversing semantics, rather than the array
> reference semantics that svn and bzr provide with refnos.  Only merges
> ("cons with multiple parents") fail to follow the pattern, but I've
> never heard anyone complain that merges are particularly hard to
> understand.[1]
> 
> What's so hard about list semantics for an Emacs developer?

First, your list of primitive objects is already an obstacle: it's too
long, and the objects are themselves too abstract.  As a user of a
VCS, I care about commits, branches, and merges, and my notion of a
"tree" is just what I see in the file system.  I don't want to know
about anything else, at least not in the beginning.  However, Git docs
keep pushing those other objects into my face on every turn.

Second, too many things in Git are different, or are done differently,
or have different effect from their namesakes in other VCSes
(a.k.a. "have different semantics".  At times, I have a distinct
feeling that Someone(TM) made a conscious effort to confuse me by
picking up a different semantics.  Examples:

  . "git checkout" is not what a "checkout" means or does in any other
    VCS I know of.  Moreover, it has several different meanings and
    effects, one of them being "revert to the last version", for
    example.

  . "bzr pull" doesn't commit; "git pull" does.  Likewise for "merge".
    (AFAIK, svn and hg both behave like bzr.)  One effect of that is
    that you need to remember to use -e if you want to add something
    to the commit log message when you merge or cherry-pick.

  . the inhumanely complex way of specifying past commits.  I miss the
    simplicity of -n..-m; the replacement @address@hidden is more to type and
    remember; the similar @address@hidden has a subtly different meaning.
    What's more, the documentation doesn't help by giving you examples
    of specs you'd frequently use, but instead insists on formally
    describing the syntax, leaving the rest to you to figure out.  The
    result is that I'm not even sure I figured out the "@address@hidden" spec
    correctly (did I?).  The other result is that to see the diffs of
    the last commit, it is much easier to use "git show" than the more
    obvious "git diff".

I could go on, but I hope you see the point: I don't want to study Git
as deep as you seem to imply.  Git is just a tool for me, and a minor
one at that, not unlike Grep or 'locate'.  Most of my work on Emacs is
not with Git, even though I need sometimes to do some VCS forensics in
order to see the history of some change.  I just want to use Git
seamlessly.  My problem, to sum it up, is that there are too many
things I need to re-learn from scratch, and too much muscle memory I
need to un-learn.

> [1]  Granted, submodules *are* hard; it's not just that tree is
> generalized to array of tree-or-blob-or-commit, but that commits also
> change semantics when used in submodules.  But we're not talking about
> submodules in Emacs yet.

I think we are, in the ELPA related discussions.  But maybe I'm
confused about that, too.