[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: git pull fails with merge conflicts. How can this possibly happen?
From: |
Eli Zaretskii |
Subject: |
Re: git pull fails with merge conflicts. How can this possibly happen? |
Date: |
Sat, 15 Nov 2014 12:54:39 +0200 |
> 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.
- git pull fails with merge conflicts. How can this possibly happen?, Alan Mackenzie, 2014/11/14
- Re: git pull fails with merge conflicts. How can this possibly happen?, David Caldwell, 2014/11/14
- Re: git pull fails with merge conflicts. How can this possibly happen?, Alan Mackenzie, 2014/11/14
- Re: git pull fails with merge conflicts. How can this possibly happen?, Yuri Khan, 2014/11/15
- Re: git pull fails with merge conflicts. How can this possibly happen?, Eli Zaretskii, 2014/11/15
- Re: git pull fails with merge conflicts. How can this possibly happen?, Stephen J. Turnbull, 2014/11/15
- Re: git pull fails with merge conflicts. How can this possibly happen?,
Eli Zaretskii <=
- Re: git pull fails with merge conflicts. How can this possibly happen?, David Engster, 2014/11/15
- Re: git pull fails with merge conflicts. How can this possibly happen?, David Kastrup, 2014/11/15
- Re: git pull fails with merge conflicts. How can this possibly happen?, Eli Zaretskii, 2014/11/15
- Re: git pull fails with merge conflicts. How can this possibly happen?, David Kastrup, 2014/11/15
- Re: git pull fails with merge conflicts. How can this possibly happen?, Eli Zaretskii, 2014/11/15
- Re: git pull fails with merge conflicts. How can this possibly happen?, Stephen J. Turnbull, 2014/11/15
- Re: git pull fails with merge conflicts. How can this possibly happen?, Eli Zaretskii, 2014/11/15
- Re: git pull fails with merge conflicts. How can this possibly happen?, David Kastrup, 2014/11/15
- Re: git pull fails with merge conflicts. How can this possibly happen?, David Kastrup, 2014/11/15
- Re: git pull fails with merge conflicts. How can this possibly happen?, Stephen J. Turnbull, 2014/11/15