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

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

[Alan Mackenzie]

Hello, Emacs.

I've now advanced from my last puzzlement.  It turns out that "git
clone" doesn't properly initialise the new repository.  I had to do this
manually with "git checkout emacs-24".  I now get a bit further with
"git pull" from my other repository.

This "git pull" leaves a mass of merge conflicts.  How can this be?  I
have not edited a single file in any git repository as of yet.  Here is
a screen shot from this "git pull" together with a preceeding "git
branch -a":

  acm@acm ~/emacs/emacs.git/emacs-24 $ git branch -a
  * emacs-24
    master
    remotes/origin/HEAD -> origin/master
    remotes/origin/emacs-24
    remotes/origin/master
  acm@acm ~/emacs/emacs.git/emacs-24 $ git pull
  remote: Counting objects: 32, done.
  remote: Compressing objects: 100% (16/16), done.
  remote: Total 32 (delta 26), reused 22 (delta 16)
  Unpacking objects: 100% (32/32), done.
  From /home/acm/emacs/emacs.git/master/.
   + 911ad4a...6688117 emacs-24   -> origin/emacs-24  (forced update)
  Auto-merging src/nsfns.m
  Auto-merging src/ChangeLog
  CONFLICT (content): Merge conflict in src/ChangeLog
  Auto-merging lisp/gnus/ChangeLog
  CONFLICT (content): Merge conflict in lisp/gnus/ChangeLog
  Auto-merging etc/ChangeLog
  CONFLICT (content): Merge conflict in etc/ChangeLog
  Auto-merging etc/CONTRIBUTE
  Auto-merging admin/ChangeLog
  CONFLICT (content): Merge conflict in admin/ChangeLog
  Auto-merging Makefile.in
  CONFLICT (content): Merge conflict in Makefile.in
  Auto-merging ChangeLog
  CONFLICT (content): Merge conflict in ChangeLog
  Auto-merging .gitignore
  CONFLICT (content): Merge conflict in .gitignore
  Automatic merge failed; fix conflicts and then commit the result.

What does git pull actually do?  The git pull man page says:

  "Incorporates changes from a remote repository into the current
   branch. In its default mode, git pull is shorthand for git fetch
   followed by git merge FETCH_HEAD."

Does this mean that git has tried to merge changes on the master branch
into my emacs-24 branch working directory?  Surely git can't be that
stupid.  Please?

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[David Caldwell]

[-- Attachment #1: Type: text/plain, Size: 2352 bytes --]

On 11/14/14 10:37 AM, Alan Mackenzie wrote:
> Hello, Emacs.
> 
> I've now advanced from my last puzzlement.  It turns out that "git
> clone" doesn't properly initialise the new repository.  I had to do this
> manually with "git checkout emacs-24".

Git checkout looks for a branch with the name "emacs-24", failing that
it looks for one matching that in your remotes/* and copies that branch
into "emacs-24". Thus remotes/origin/emacs-24 should be copied to
emacs-24 (and you can check this in the .git/refs/* directory tree +
.git/packed-refs file—it's all text).

> This "git pull" leaves a mass of merge conflicts.  How can this be?
> What does git pull actually do?  The git pull man page says:
>
>   "Incorporates changes from a remote repository into the current
>    branch. In its default mode, git pull is shorthand for git fetch
>    followed by git merge FETCH_HEAD."

The man page is correct.

>   acm@acm ~/emacs/emacs.git/emacs-24 $ git branch -a
>   * emacs-24
>     master
>     remotes/origin/HEAD -> origin/master
>     remotes/origin/emacs-24
>     remotes/origin/master
>   acm@acm ~/emacs/emacs.git/emacs-24 $ git pull

This is the "git fetch" part of "git pull":

>   remote: Counting objects: 32, done.
>   remote: Compressing objects: 100% (16/16), done.
>   remote: Total 32 (delta 26), reused 22 (delta 16)
>   Unpacking objects: 100% (32/32), done.
>   From /home/acm/emacs/emacs.git/master/.

This is the "git merge" part:

>    + 911ad4a...6688117 emacs-24   -> origin/emacs-24  (forced update)

The problem is the 911ad4a. If you look at that commit it is on the
master branch. This implies that your local emacs-24 branch was not
*really* the emacs-24 branch (Maybe you accidentally did "git checkout
-b emacs-24"?).

Git matched the "emacs-24" name to the "origin/emacs-24" and merged that
in, but since your emacs-24 branch was was really just master you got a
bunch of merge conflicts.

That is my guess anyway, it's hard to tell without seeing your repo. If
you "git reset" then "git log", which commit is first? If it's the
911ad4a then you aren't really on the emacs-24 branch.

You can try poking around with gitk to see how the branches interact. I
also quite like the "tig" tool (not part of git)—it's sort of a curses
version of gitk.

-David



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4219 bytes --]

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

[Alan Mackenzie]

Hello, David.

On Fri, Nov 14, 2014 at 11:01:15AM -0800, David Caldwell wrote:
> On 11/14/14 10:37 AM, Alan Mackenzie wrote:
> > I've now advanced from my last puzzlement.  It turns out that "git
> > clone" doesn't properly initialise the new repository.  I had to do this
> > manually with "git checkout emacs-24".

> Git checkout looks for a branch with the name "emacs-24", failing that
> it looks for one matching that in your remotes/* and copies that branch
> into "emacs-24". Thus remotes/origin/emacs-24 should be copied to
> emacs-24 (and you can check this in the .git/refs/* directory tree +
> .git/packed-refs file—it's all text).

How come "git clone" didn't work properly?  Surely the branch structure
in the original and the copy repositories should be identical.  That's
what "cloning" means.

What exactly is this "remotes/*".  When you talk about "copies that
branch into "emacs-24"", is this copying within the repository, or from
another repository into this one.  Where is this described?

> > This "git pull" leaves a mass of merge conflicts.  How can this be?
> > What does git pull actually do?  The git pull man page says:

> >   "Incorporates changes from a remote repository into the current
> >    branch. In its default mode, git pull is shorthand for git fetch
> >    followed by git merge FETCH_HEAD."

> The man page is correct.

:-)

> >   acm@acm ~/emacs/emacs.git/emacs-24 $ git branch -a
> >   * emacs-24
> >     master
> >     remotes/origin/HEAD -> origin/master
> >     remotes/origin/emacs-24
> >     remotes/origin/master
> >   acm@acm ~/emacs/emacs.git/emacs-24 $ git pull

I notic here that "emacs-24" has the *, but "remotes/origin/HEAD" ->
"origin/master".  Could this have something to do with my failed git
pull?  Unfortunately, only the syntax of "remotes" is described in the
git glossary, not its semantics.

> This is the "git fetch" part of "git pull":

> >   remote: Counting objects: 32, done.
> >   remote: Compressing objects: 100% (16/16), done.
> >   remote: Total 32 (delta 26), reused 22 (delta 16)
> >   Unpacking objects: 100% (32/32), done.
> >   From /home/acm/emacs/emacs.git/master/.

> This is the "git merge" part:

> >    + 911ad4a...6688117 emacs-24   -> origin/emacs-24  (forced update)

> The problem is the 911ad4a. If you look at that commit it is on the
> master branch. This implies that your local emacs-24 branch was not
> *really* the emacs-24 branch (Maybe you accidentally did "git checkout
> -b emacs-24"?).

I don't think I did, but anything's possible.

> Git matched the "emacs-24" name to the "origin/emacs-24" and merged that
> in, but since your emacs-24 branch was was really just master you got a
> bunch of merge conflicts.

> That is my guess anyway, it's hard to tell without seeing your repo. If
> you "git reset" then "git log", which commit is first? If it's the
> 911ad4a then you aren't really on the emacs-24 branch.

It's too late at night to start trying to make sense of the git reset man
page.  I'll have a look at that tomorrow.

> You can try poking around with gitk to see how the branches interact. I
> also quite like the "tig" tool (not part of git)—it's sort of a curses
> version of gitk.

gitk doesn't work on my system, of course.  (Nothing ever does without a
lot of effort).  Funny thing: looking at the gitk man page, there doesn't
appear to be a way of specifying the repository.  Hmm.

> -David

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Yuri Khan]

On Sat, Nov 15, 2014 at 3:54 AM, Alan Mackenzie <acm@muc.de> wrote:

> gitk doesn't work on my system, of course.  (Nothing ever does without a
> lot of effort).

I want to propose a couple of rules of thumb for beginner Git users.


Rule First:

* Drop everything else you’re trying to do with Git and get
comfortable with at least one Git repository browser. One that
displays pretty graphs.

Starting with Git without a graph browser is like learning chess by
playing blind.

At a minimum, this command is always available:

$ git log --graph --decorate --oneline --color <branch>…


Rule Second:

* Do not ever use “git pull”.

“git pull” does two things. First, it will bring into your local
repository new commits[1] from the remote, and rearrange the remote
tracking branch heads[2] to match their current positions in the
remote. Second, it will try to match[3] your local branch head with a
remote tracking branch head, and merge that into your local branch.

[1] This set of commits is unpredictable and depends on the past
actions of many other people.
[2] The motion of remote tracking branches is unpredictable and
depends on the past actions of many other people.
[3] The matching of the local branch to the corresponding remote
tracking branch is predictable and depends only on your own actions.
But still it is often surprising.

Instead:

1. Cautiously “git fetch” new remote state into your local repo.
2. Explore the changes with a graph browser, at least for the few
branches you are directly interested in (emacs-24 and master). See if
any of the remote branches diverged with your local branches.
3. Decide if you want a merge, a rebase, a cherry-pick, or something
else entirely. (I have seen cases when the remote had changed so much
that it was easier to reimplement a feature on top of the new remote
state than try to merge or rebase.)


Also, required reading/watching:

* Git Pro, book by Scott Chacon
* Git For Ages 4 and Up, talk by Michael Schwern


> Funny thing: looking at the gitk man page, there doesn't
> appear to be a way of specifying the repository.  Hmm.

By convention, all git commands assume they are run within the
repository. So just cd into the repo first.

Some features in gitk also assume it has been run in the repository
root. (Arguably this is a bug but apparently no one has yet gotten
around to fix it.)

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

[Eli Zaretskii]

> Date: Sat, 15 Nov 2014 12:41:12 +0700
> From: Yuri Khan <yuri.v.khan@gmail.com>
> Cc: Emacs developers <emacs-devel@gnu.org>, David Caldwell <david@porkrind.org>
> 
> On Sat, Nov 15, 2014 at 3:54 AM, Alan Mackenzie <acm@muc.de> wrote:
> 
> > gitk doesn't work on my system, of course.  (Nothing ever does without a
> > lot of effort).
> 
> I want to propose a couple of rules of thumb for beginner Git users.

I'm sorry, but after using Git for a year on several live projects, I
cannot disagree more with your rules.  They in fact make a research
project from each synchronization with upstream and each browsing of
the commit history.  There's no justification for such complexity,
certainly not for beginners.  Your suggestions are in fact
anti-pedagogical, because they turn the learning process on its head:
instead of starting with simple stuff, then gradually learning more
and deeper, you suggest that they start with the complex stuff first.
This makes very little sense to me.

I don't use gitk or anything similar, and yet I have no problems
looking at the commit log.  I don't feel blind.  I also never needed
to use 'fetch', except exactly once, when Andreas deleted a branch --
something that shouldn't happen frequently, so it's an exception
rather than the rule.  No problems with "git pull" here, none
whatsoever.  (And yes, from my 1-year experience place I do know about
the pitfalls of 'pull', I just never saw them in any of the projects
I'm involved in.  Spreading FUD of the kind that you did about 'pull'
is IMO making a disservice to those whom you want to help.)

Bottom line, if the beginners follow some simple workflow, like the
one written on the Wiki, they will never get themselves in trouble
with 'log' and 'pull'.

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, and I still don't feel comfortable with Git as I do
with bzr and CVS.  But I can assure everyone here that Yuri's rules do
not need to be followed in order to use Git correctly and almost
seamlessly.  Just find your preferred workflow, document it in some
notes if you don't trust your memory, and follow it every day.  You
don't need to know any fancy complicated commands.

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

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > Date: Sat, 15 Nov 2014 12:41:12 +0700
 > > From: Yuri Khan <yuri.v.khan@gmail.com>
 > > Cc: Emacs developers <emacs-devel@gnu.org>, David Caldwell <david@porkrind.org>
 > > 
 > > On Sat, Nov 15, 2014 at 3:54 AM, Alan Mackenzie <acm@muc.de> wrote:
 > > 
 > > > gitk doesn't work on my system, of course.  (Nothing ever does without a
 > > > lot of effort).
 > > 
 > > I want to propose a couple of rules of thumb for beginner Git users.
 > 
 > I'm sorry, but after using Git for a year on several live projects, I
 > cannot disagree more with your rules.

+1 to Eli's comment, -1 to those rules.  They make some sense for
developers who are working on feature branches in a free-branching
project with weak gatekeeping, but in a project with a strong sense of
trunk like Emacs they are unnecessarily complex, especially for people
not working on long-lived feature branches.

 > 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: 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?


Footnotes: 
[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.

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

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Yuri Khan <yuri.v.khan@gmail.com>,
>     acm@muc.de,
>     david@porkrind.org,
>     emacs-devel@gnu.org
> 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 @~n..@~m is more to type and
    remember; the similar @{n}..@{m} 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 "@~n..@~m" 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.

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

[David Engster]

Eli Zaretskii writes:
> At times, I have a distinct feeling that Someone(TM) made a conscious
> effort to confuse me by picking up a different semantics.

That's because Git was designed as a "stupid content tracker". The in
this thread often mentioned "Git Pro" book says it right up front: "Git
thinks of its data more like a set of snapshots of a miniature
filesystem" [1]. You really have to fully embrace that notion to get
comfortable with Git (to a certain degree...).

>> [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.

Submodules would be an option if each package we want to bundle with
Emacs was in its own repository. However, since they are all in
elpa.git, I don't think it makes much sense to import it as a submodule,
especially since this introduces a lot of additional complexity into the
workflow.

-David

[1] http://git-scm.com/book/en/v2/Getting-Started-Git-Basics

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

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>   . "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.

I think -e is the default for merging these days.  At any rate, you can
fix up the message with

git commit --amend

afterwards.

>   . the inhumanely complex way of specifying past commits.  I miss the
>     simplicity of -n..-m; the replacement @~n..@~m is more to type and
>     remember; the similar @{n}..@{m} has a subtly different meaning.

Not subtle at all, actually.  @{n}..@{m} seems basically useless.  It
may work as an argument to git-reflog but I am not sure about that.
Basically, you'd only use @{n} for single commits.

>     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 "@~n..@~m" spec
>     correctly (did I?).

I never heard or read of it.  I rather use HEAD~n or HEAD~m when
referring to the current head but indeed, @ is documented as a shortcut
for HEAD on its own.  Which seems like a really stupid idea since it
means that HEAD@{1} is different from @{1} but is the same as @@{1}.
That is an overload of meaning that one could have well done without...

I'd recommend that you keep away from @~n if you don't want to confuse
other Emacs users.  HEAD~n will be more meaningful to people.

-- 
David Kastrup

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

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Sat, 15 Nov 2014 12:19:09 +0100
> 
> I'd recommend that you keep away from @~n if you don't want to confuse
> other Emacs users.  HEAD~n will be more meaningful to people.

It's a lot more to type, though.

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

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Sat, 15 Nov 2014 12:19:09 +0100
>> 
>> I'd recommend that you keep away from @~n if you don't want to confuse
>> other Emacs users.  HEAD~n will be more meaningful to people.
>
> It's a lot more to type, though.

English is a lot more to type than APL, but last time I looked, the
point of communication was not using the minimal amount of characters
that one can claim "are still correct".

-- 
David Kastrup

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

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 15 Nov 2014 15:38:00 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: David Kastrup <dak@gnu.org>
> >> Date: Sat, 15 Nov 2014 12:19:09 +0100
> >> 
> >> I'd recommend that you keep away from @~n if you don't want to confuse
> >> other Emacs users.  HEAD~n will be more meaningful to people.
> >
> > It's a lot more to type, though.
> 
> English is a lot more to type than APL, but last time I looked, the
> point of communication was not using the minimal amount of characters
> that one can claim "are still correct".

I'm not talking about communicating with humans, so this aspect
doesn't bother me in this case.

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

[Stephen J. Turnbull]

David Kastrup writes:

 > Which seems like a really stupid idea since it means that HEAD@{1}
 > is different from @{1} but is the same as @@{1}.

No, they all mean the same thing AFAICT.  The first and third are
obviously the same.  The second is defined as meaning <current>@{1},
but I believe that <current> is implemented by dereffing HEAD.  I'm
not sure what happens if HEAD is detached, but that will happen
regardless of which notation you use.

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

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Sun, 16 Nov 2014 01:31:23 +0900
> Cc: emacs-devel@gnu.org
> 
> David Kastrup writes:
> 
>  > Which seems like a really stupid idea since it means that HEAD@{1}
>  > is different from @{1} but is the same as @@{1}.
> 
> No, they all mean the same thing AFAICT.

That's my conclusion as well, but you won't find that in the docs.
The description of @{n} explicitly mentions "reflog", but the
description of REFNAME@{n} only hints on that.

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

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Stephen J. Turnbull" <stephen@xemacs.org>
>> Date: Sun, 16 Nov 2014 01:31:23 +0900
>> Cc: emacs-devel@gnu.org
>> 
>> David Kastrup writes:
>> 
>>  > Which seems like a really stupid idea since it means that HEAD@{1}
>>  > is different from @{1} but is the same as @@{1}.
>> 
>> No, they all mean the same thing AFAICT.
>
> That's my conclusion as well, but you won't find that in the docs.
> The description of @{n} explicitly mentions "reflog", but the
> description of REFNAME@{n} only hints on that.

dak@lola:/usr/local/tmp/lilypond$ git checkout issue216
Previous HEAD position was 2a67ab2... Doc: Document unit of \abs-fontsize
Switched to branch 'issue216'
Your branch is ahead of 'origin/master' by 2 commits.
  (use "git push" to publish your local commits)
dak@lola:/usr/local/tmp/lilypond$ git reflog -1 @{4}
fatal: Log for 'issue216' only has 4 entries.
dak@lola:/usr/local/tmp/lilypond$ git reflog -1 @@{4}
2a67ab2 HEAD@{4}: checkout: moving from 2a67ab2aee4e826c1998684249ecd2e862e4804c

-- 
David Kastrup

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

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> David Kastrup writes:
>
>  > Which seems like a really stupid idea since it means that HEAD@{1}
>  > is different from @{1} but is the same as @@{1}.
>
> No, they all mean the same thing AFAICT.

Not if you changed branches recently.  @{1} refers to the reflog of the
current branch, HEAD@{1} or @@{1} are the reflog of the whole
repository, including all branch switches.

> The first and third are obviously the same.  The second is defined as
> meaning <current>@{1}, but I believe that <current> is implemented by
> dereffing HEAD.

Nope.

> I'm not sure what happens if HEAD is detached, but that will happen
> regardless of which notation you use.

@{1} will then revert to the global reflog and then all three are
indeed equal.  But not with a branch checked out.

-- 
David Kastrup

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

[Stephen J. Turnbull]

David Kastrup writes:

 > Not if you changed branches recently.  @{1} refers to the reflog of the
 > current branch, HEAD@{1} or @@{1} are the reflog of the whole
 > repository, including all branch switches.

Ah, I see, now.  For this purpose the content of HEAD is (usually)
another ref, and the reflog for HEAD is different from the reflog for
the ref it contains.  (I wouldn't call that the "reflog of the whole
repository", though.)  I still don't have a problem with @ = HEAD in
contexts where a ref is expected.  It's not uncommon for X to mean
something different from XX, so it's OK that @{1} != @@{1} for me.

git apologia [was: git pull fails with merge conflicts. ...]

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > 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,

It's *all* of the ones that matter.  You can ignore the internal
structure of trees.  And only "ref" is primitive, "tag" and "branch"
are derived from "ref".

But most important, as an Emacs developer, you understand how conses
work, and how to manipulate a Lisp list using car and cdr and push.
So you don't need to study "git semantics" *at all*, because you
already have a wealth of experience with them, once you grasp the
(very accurate) analogy.

 > 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,

[...]
 > 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".

"<program> <command> has different semantics" is not what I understand
when someone says "I don't understand <program>'s semantics."

But OK, yes, that's an issue users would (justifiably) rather not deal
with.  If that's all you meant by "don't understand git semantics",
you have my sympathy, but I think the majority of Emacs developers are
going to be very pleased by the efficiency and power of git, and even
you may find after a few months that vc and/or magit have improved to
the point where you don't have to deal with git CLI at all any more.

A few random comments:

 > The result is that I'm not even sure I figured out the "@~n..@~m"
 > spec correctly (did I?).

You did.

 > 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".

"git diff <commit>" has historical, and useful, semantics.  IMHO,
"git show <commit>" is a surprisingly elegant UI for what it does,
considering that this is git. :-)

Sure, they *could* have implemented "git diff -c" as hg and bzr do,
but I like "git show" better.  YMMV.

 > > 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.

Ah, you're not confused.  There's been hot air vaporing about.  But I
don't think anybody who matters (= Stefan) is serious about it yet.

And rightly so.  The semantics of submodules are very subtle.  We use
hg subrepos in the XEmacs package repository, and it's a continuing
source of issues.  It's quite manageable, but mostly because we're a
very tight[1] community, and have a single package release manager
responsible for curating them.  I would expect much more trouble, at
least initially, in ELPA, because of the number and variety of package
maintainers, and individual maintainers in ELPA are responsible for
some things that Norbert takes care of for all XEmacs packages.

Footnotes: 
[1]  Read "small", but don't tell anyone I said that. :-)

Re: git apologia [was: git pull fails with merge conflicts. ...]

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: emacs-devel@gnu.org
> Date: Sun, 16 Nov 2014 01:25:30 +0900
> 
> But most important, as an Emacs developer, you understand how conses
> work, and how to manipulate a Lisp list using car and cdr and push.
> So you don't need to study "git semantics" *at all*, because you
> already have a wealth of experience with them, once you grasp the
> (very accurate) analogy.

I understand that.  My point is that, while I do want to reason in
these terms about Emacs, which I help developing, I prefer not to have
to reason about Git in any similar way or to a similar depth.  I just
need to get the job done quickly, efficiently, and without errors.
Again, using Git is tangential to my interest here, which is develop
Emacs.  I don't want to know about its internals more than I know
about GCC, for example.

> "<program> <command> has different semantics" is not what I understand
> when someone says "I don't understand <program>'s semantics."

Well, I'll take my "English is not my first language" refuge here.

> But OK, yes, that's an issue users would (justifiably) rather not deal
> with.  If that's all you meant by "don't understand git semantics",

I did.

> you have my sympathy, but I think the majority of Emacs developers are
> going to be very pleased by the efficiency and power of git, and even
> you may find after a few months that vc and/or magit have improved to
> the point where you don't have to deal with git CLI at all any more.

I wasn't arguing for dropping Git, okay?  You asked me what was
confusing, and I explained in response what makes the learning curve
steeper than it could have been.  Once the decision was made to switch
to Git, I don't think anyone here heard me complaining (unlike what we
heard about bzr).

>  > 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".
> 
> "git diff <commit>" has historical, and useful, semantics.  IMHO,
> "git show <commit>" is a surprisingly elegant UI for what it does,
> considering that this is git. :-)
> 
> Sure, they *could* have implemented "git diff -c" as hg and bzr do,
> but I like "git show" better.  YMMV.

MMDNV.  But the point is that I need either forget about "git diff"
and switch to "git show" entirely, or use the former as replacement
for the "-c COMMIT" use case, and the latter for the others.  IOW, one
more thing to re-learn, that won't serve me with any other VCS.

Re: git apologia [was: git pull fails with merge conflicts. ...]

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > I understand that.  My point is that, while I do want to reason in
 > these terms about Emacs, which I help developing, I prefer not to have
 > to reason about Git in any similar way or to a similar depth.  I just
 > need to get the job done quickly, efficiently, and without errors.

You don't have that choice of "just" if you use CLI git.

 > > you have my sympathy, but I think the majority of Emacs developers are
 > > going to be very pleased by the efficiency and power of git, and even
 > > you may find after a few months that vc and/or magit have improved to
 > > the point where you don't have to deal with git CLI at all any more.
 > 
 > I wasn't arguing for dropping Git, okay?

I didn't say you were.  You did say that there are things you don't
like about it (which you would have kept to yourself if not asked
directly), and I'm just saying that maybe it will get better (and you
can get off the learning curve entirely at that point).

 > IOW, one more thing to re-learn, that won't serve me with any other
 > VCS.

As Eric said, "git has won."  Heck, even Tom Lord (remember Tom Lord?)
said that git got the basics right, and used the git object database
as the foundation for his new VCS, revc.

Re: git apologia [was: git pull fails with merge conflicts. ...]

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Eli Zaretskii writes:
>
>  > IOW, one more thing to re-learn, that won't serve me with any other
>  > VCS.
>
> As Eric said, "git has won."  Heck, even Tom Lord (remember Tom Lord?)
> said that git got the basics right, and used the git object database
> as the foundation for his new VCS, revc.

Well, it's like a Bosch car.  Lots of well-engineered components.  It's
left as an exercise to the driver to define a car from those.

-- 
David Kastrup

Git's victory and an entertaining irony

[Eric S. Raymond]

Stephen J. Turnbull <stephen@xemacs.org>:
> As Eric said, "git has won."  Heck, even Tom Lord (remember Tom Lord?)
> said that git got the basics right, and used the git object database
> as the foundation for his new VCS, revc.

While I am still of this opinion with respect to changeset-oriented
VCSes, something ironically funny happened last week.  I wrote a new
VCS that violates the crap out of most modern assumptions about VCS
design.  And it's a success at version 0.8 - has real users and a
growing dev community.

Yes.  That's right.  I wrote a VCS.  Took me 14 hours to go from 
concept to shippable, documented 0.1.  (Thank you, Python.)

Here's why.  I noticed something about my work habits.  Which is that
even though I judge git has won, it's not the only version-control
system I use.  A significant percentage of my files are maintained in
RCS through VC.  And there's a reason for this that isn't pure inertia.

I have some directories full of single-file projects - FAQs, manuscripts, 
small shellscripts, that sort of thing (my ~/bin is one of them).  I use
RCS on these because I want each file to have a version-control history 
but one that is *separate from the others*.  This exactly violates the 
root assumption of modern VCSes, which designed to manage entire directories
(and subdirectories) with joint histories.

So I asked myself: what would a VCS *specifically designed for this use case
look like*?  There are kluges to address it, with unlovely names like "zit"
(a wrapper around git), but they all throw away at least one desirable 
feature of RCS, which is no binary blobs.  An RCS file is a textfile (unless
you explicitly insert binary data in it).  There are fundamental reasons
this is a Good Thing which I trust I not have to explain on *this* list.

Then I thought: I could wrap RCS in Python, keep the readable history
format, and hide all the ugly crap like RCS version numbers and the
forty kajillion RCS invocation switches.  Then I wrote the manual page.

I called it SRC, "Simple Revision Control", an anagram of RCS.

I wrote the manual page *first*.  I did this because I wanted to think
through the user-interface issues without having my thinking distorted by
implementation issues and the temptation to take wrong shortcuts.

What came out looked like this:

1. Integer revision numbers monotonically increasing a la Subversion.
   This was the single most important decision - they're great if you
   have a centralized file store, and RCS's native revision numbering
   is *nasty*.

2. Lockless operation.  Workfiles are, unlike bare RCS, normally writeable.

3. CLI patterned on Subversion and hg.  "src checkout <file>" does what you
   think it does.  So does "src commit <file>", "src log <file>" and
   "src status".

4. Named tags and branches that work just like you think they should from 
   other systems.  A tag is a named synonym for a numbered revision hat can be
   used in ranges.

5. Two kinds of range literal: M..N follows branch structure, M-N ignores it.

6. Both export and import via fast-import streams. If your project grows
   up enough to become multi-file, you just push a button...

It's deliberately a conservative design with no surprises - the two kinds
of range literal are the closest thing to an innovation in the interface.
My goal was for it to feel ready to the hand of anyone with prior 
experience of the major VCSes.  My alpha users assure me that I have
succeeded in this.

Yes, I will write VC support.

It's already packaged in the Arch user repository.  I have contributions
from three devs besides myself.  About half a dozen users I know of, probably
more I don't.  This is day nine of its life.

SRC: http://www.catb.org/esr/src/

SRC FAQ: http://www.catb.org/esr/src/FAQ.html

And yes. I do think it's funny.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Git's victory and an entertaining irony

[Stephen J. Turnbull]

Eric S. Raymond writes:

 > So I asked myself: what would a VCS *specifically designed for this
 > use case look like*?

vc.el!

Re: Git's victory and an entertaining irony

[Eric S. Raymond]

Stephen J. Turnbull <stephen@xemacs.org>:
> Eric S. Raymond writes:
> 
>  > So I asked myself: what would a VCS *specifically designed for this
>  > use case look like*?
> 
> vc.el!

But no. It wasn't.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: git apologia [was: git pull fails with merge conflicts. ...]

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> MMDNV.  But the point is that I need either forget about "git diff"
> and switch to "git show" entirely, or use the former as replacement
> for the "-c COMMIT" use case, and the latter for the others.  IOW, one
> more thing to re-learn, that won't serve me with any other VCS.

You still need git diff for showing the changes in your work tree
wrt. HEAD, or the index.  git show is about showing the contents of an
object, be it a commit or a tree or a blob.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: git apologia [was: git pull fails with merge conflicts. ...]

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: "Stephen J. Turnbull" <stephen@xemacs.org>,  emacs-devel@gnu.org
> Date: Sat, 15 Nov 2014 19:26:19 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > MMDNV.  But the point is that I need either forget about "git diff"
> > and switch to "git show" entirely, or use the former as replacement
> > for the "-c COMMIT" use case, and the latter for the others.  IOW, one
> > more thing to re-learn, that won't serve me with any other VCS.
> 
> You still need git diff for showing the changes in your work tree
> wrt. HEAD, or the index.

Right.  Which is why I only use show after a commit before a push.

Re: git apologia [was: git pull fails with merge conflicts. ...]

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Cc: "Stephen J. Turnbull" <stephen@xemacs.org>,  emacs-devel@gnu.org
>> Date: Sat, 15 Nov 2014 19:26:19 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > MMDNV.  But the point is that I need either forget about "git diff"
>> > and switch to "git show" entirely, or use the former as replacement
>> > for the "-c COMMIT" use case, and the latter for the others.  IOW, one
>> > more thing to re-learn, that won't serve me with any other VCS.
>> 
>> You still need git diff for showing the changes in your work tree
>> wrt. HEAD, or the index.
>
> Right.  Which is why I only use show after a commit before a push.

My most common use is

git show <commit-SHA1>:VERSION

since LilyPond keeps its current version number in ./VERSION.  That way,
once I figure out that commit <commit-SHA1> was responsible for fixing a
particular bug, I can then post "this was fixed in version xx.xx.xx with
commit
<copy-and-paste of the commit portion of git show <commit-SHA1>>
"

-- 
David Kastrup

Re: git apologia

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Sun, 16 Nov 2014 01:25:30 +0900
> Cc: emacs-devel@gnu.org
> 
> Eli Zaretskii writes:
> 
>  > The result is that I'm not even sure I figured out the "@~n..@~m"
>  > spec correctly (did I?).
> 
> You did.

Actually, it turns out neither this nor HEAD~n is what I want.  What I
want is to display information about commits N..M where N and M are
ordinal numbers from the linear "git log" output.  And waddaya know?
HEAD~n etc. seem to _skip_ merge-commits, so (a) the counts end up
being wrong, and (b) if you want to see those merge-commits, you need
to _know_ they are merge-commits and then use HEAD^2 etc. (i.e.
explicitly request the 2nd parent).  This is awful.

The result is that to simulate bzr's "diff -r-N..-M" functionality I
had to write a special-purpose alias, using "log --skip=N -nM -p -c",
in order to be able to display the diffs of a range of commits that
include merge-commits.  Ugh!  (Or maybe I missed some magic that
allows to do this with less pain.)

Re: git apologia

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> Actually, it turns out neither this nor HEAD~n is what I want.  What I
> want is to display information about commits N..M where N and M are
> ordinal numbers from the linear "git log" output.  And waddaya know?
> HEAD~n etc. seem to _skip_ merge-commits,

Just like bzr does with its ordinal numbers.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: git apologia

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: "Stephen J. Turnbull" <stephen@xemacs.org>,  emacs-devel@gnu.org
> Date: Sun, 16 Nov 2014 17:36:41 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Actually, it turns out neither this nor HEAD~n is what I want.  What I
> > want is to display information about commits N..M where N and M are
> > ordinal numbers from the linear "git log" output.  And waddaya know?
> > HEAD~n etc. seem to _skip_ merge-commits,
> 
> Just like bzr does with its ordinal numbers.

No, bzr shows the merge-commit on the mainline, with a normal
(i.e. non-dotted) number.  Only the commits on the branch from which
we merged are skipped by default by "bzr log".

Re: git apologia

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Cc: "Stephen J. Turnbull" <stephen@xemacs.org>,  emacs-devel@gnu.org
>> Date: Sun, 16 Nov 2014 17:36:41 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Actually, it turns out neither this nor HEAD~n is what I want.  What I
>> > want is to display information about commits N..M where N and M are
>> > ordinal numbers from the linear "git log" output.  And waddaya know?
>> > HEAD~n etc. seem to _skip_ merge-commits,
>> 
>> Just like bzr does with its ordinal numbers.
>
> No, bzr shows the merge-commit on the mainline, with a normal
> (i.e. non-dotted) number.  Only the commits on the branch from which
> we merged are skipped by default by "bzr log".

And how is that different from the counting of HEAD~n?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: git apologia

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: stephen@xemacs.org,  emacs-devel@gnu.org
> Date: Sun, 16 Nov 2014 19:20:51 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > No, bzr shows the merge-commit on the mainline, with a normal
> > (i.e. non-dotted) number.  Only the commits on the branch from which
> > we merged are skipped by default by "bzr log".
> 
> And how is that different from the counting of HEAD~n?

The merge-commits don't show using HEAD~n.

Here's an example.  With the current trunk, the 10th and 11th entries
shown by "git log" are for merge-commits made by Stefan.  But if I
type

  git show HEAD~10

I see the 12th commit, the one by Oscar.  And HEAD~9 is the one before
the two Stefan's commits.

By contrast, with bzr I do see merge-commits as if they were mainline
commits:

  bzr log -c-12
  118349: Glenn Morris 2014-11-10 [merge] Merge from emacs-24; up to 117702

Am I doing something wrong?

Re: git apologia

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> Here's an example.  With the current trunk, the 10th and 11th entries
> shown by "git log" are for merge-commits made by Stefan.

bzr log would not list them, since they are only reachable from the
second parent of bc5d86f.

> Am I doing something wrong?

You should use git log --first-parent.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: git apologia

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: stephen@xemacs.org,  emacs-devel@gnu.org
> Date: Sun, 16 Nov 2014 19:50:33 +0100
> 
> You should use git log --first-parent.

It doesn't seem to help, not if I do

  git log --first-parent HEAD~n

Re: git apologia

[Teemu Likonen]

[-- Attachment #1: Type: text/plain, Size: 323 bytes --]

Eli Zaretskii [2014-11-16 20:38:21 +02:00] wrote:

> The merge-commits don't show using HEAD~n.

X~n notation shouldn't have anything to do with showing merge commits.
It just goes n steps ahead from X in the first-parent line (the
left-parent line in "log --graph" view) and starts showing the history
From there.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: git apologia

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Actually, it turns out neither this nor HEAD~n is what I want.  What I
 > want is to display information about commits N..M where N and M are
 > ordinal numbers from the linear "git log" output.

I'm not sure how you would go about doing that in git.  The ~ notation
follows first parents, as "bzr log -n1" would.  Your use of --skip
seems to be the best way to accomplish what you want.q

 > And waddaya know?  HEAD~n etc. seem to _skip_ merge-commits,

It only seems to do so.  In my (not quite up-to-date) emacs repo,
"git log @~10..@~1" displays no merges, but apparently that's because
there's a long sequence of non-merges (fast-forwards) on mainline.
However, "git log @~10..@" displays several, as does
"git log @10..@^2~1".

Or by "merge-commits" do you mean the off-trunk commits?

 > so (a) the counts end up being wrong, and (b) if you want to see
 > those merge-commits, you need to _know_ they are merge-commits and
 > then use HEAD^2 etc. (i.e.  explicitly request the 2nd parent).
 > This is awful.

If you say so, I guess it is for you.  I'm curious why it's useful to
you.  In the situation I imagine, I typically fire up another terminal
and do "git log | less" rather than try to guess at appropriate n and
m.  Or use gitk.  Is it just that those aren't quite as efficient for
you, or do you have a different purpose for -n..-m?

Re: git apologia

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: emacs-devel@gnu.org
> Date: Mon, 17 Nov 2014 09:14:14 +0900
> 
>  > And waddaya know?  HEAD~n etc. seem to _skip_ merge-commits,
> 
> It only seems to do so.  In my (not quite up-to-date) emacs repo,
> "git log @address@hidden" displays no merges, but apparently that's because
> there's a long sequence of non-merges (fast-forwards) on mainline.
> However, "git log @~10..@" displays several, as does
> "git log @address@hidden".
> 
> Or by "merge-commits" do you mean the off-trunk commits?

Yes, it turns out that's what they were, as Andreas pointed out.  I
was fooled by the fact that they are shown by default (unlike what I'm
used to with bzr), and they seem to have no visual cues in the default
output format that they are off-trunk (like, e.g., the indentation
used by "bzr log").

>  > so (a) the counts end up being wrong, and (b) if you want to see
>  > those merge-commits, you need to _know_ they are merge-commits and
>  > then use HEAD^2 etc. (i.e.  explicitly request the 2nd parent).
>  > This is awful.
> 
> If you say so, I guess it is for you.  I'm curious why it's useful to
> you.

Because it is easy enough to count lines in "git log --oneline" or
similar 1-line log format, and then request details about the Nth
line.

When I pull from upstream, I almost always look at the log summary
lines of the last dozen commits, and then frequently examine one or
more of those in detail.  So I need a quick and convenient method of
doing "git show" or its equivalent without the need to type the 7 hex
characters of the SHA1 checksum.  What's more natural than asking for
the Nth previous commit?

I will probably convince myself to add --first-parent to my "git log"
aliases, as Andreas suggested.  After all, that's what "bzr log" does
by default.  Then HEAD~n will work as I expect.  (And don't get me
started on the reader-unfriendly description of --first-parent on the
git-log man page.)

Or maybe I will start using "C-x v L" ;-)

Thanks.

Re: git apologia

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> When I pull from upstream, I almost always look at the log summary
> lines of the last dozen commits, and then frequently examine one or
> more of those in detail.  So I need a quick and convenient method of
> doing "git show" or its equivalent without the need to type the 7 hex
> characters of the SHA1 checksum.  What's more natural than asking for
> the Nth previous commit?

Copy and paste from the output of git pull, which tells you exactly what
has changed.  Pass that to git log.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: git apologia

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Cc: "Stephen J. Turnbull" <stephen@xemacs.org>,  emacs-devel@gnu.org
> Date: Mon, 17 Nov 2014 17:50:55 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > When I pull from upstream, I almost always look at the log summary
> > lines of the last dozen commits, and then frequently examine one or
> > more of those in detail.  So I need a quick and convenient method of
> > doing "git show" or its equivalent without the need to type the 7 hex
> > characters of the SHA1 checksum.  What's more natural than asking for
> > the Nth previous commit?
> 
> Copy and paste from the output of git pull, which tells you exactly what
> has changed.  Pass that to git log.

Yes, that's another way.  Thanks.

Re: git apologia

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Stephen J. Turnbull" <stephen@xemacs.org>
>> Cc: emacs-devel@gnu.org
>> Date: Mon, 17 Nov 2014 09:14:14 +0900
>> 
>>  > And waddaya know?  HEAD~n etc. seem to _skip_ merge-commits,
>> 
>> It only seems to do so.  In my (not quite up-to-date) emacs repo,
>> "git log @address@hidden" displays no merges, but apparently that's because
>> there's a long sequence of non-merges (fast-forwards) on mainline.
>> However, "git log @~10..@" displays several, as does
>> "git log @address@hidden".
>> 
>> Or by "merge-commits" do you mean the off-trunk commits?
>
> Yes, it turns out that's what they were, as Andreas pointed out.  I
> was fooled by the fact that they are shown by default (unlike what I'm
> used to with bzr), and they seem to have no visual cues in the default
> output format that they are off-trunk (like, e.g., the indentation
> used by "bzr log").

git log --graph

> I will probably convince myself to add --first-parent to my "git log"
> aliases, as Andreas suggested.  After all, that's what "bzr log" does
> by default.  Then HEAD~n will work as I expect.  (And don't get me
> started on the reader-unfriendly description of --first-parent on the
> git-log man page.)
>
> Or maybe I will start using "C-x v L" ;-)

No need for a smilie.  VC is supposed to provide unifying workflows, and
Git is supposed to be flexible enough for a variety of workflows.
Making use of preexisting work for matching Git to workflows you are
more comfortable with is pretty much what VC is about.

-- 
David Kastrup

Re: git apologia

[Achim Gratz]

Eli Zaretskii writes:
> When I pull from upstream, I almost always look at the log summary
> lines of the last dozen commits, and then frequently examine one or
> more of those in detail.  So I need a quick and convenient method of
> doing "git show" or its equivalent without the need to type the 7 hex
> characters of the SHA1 checksum.  What's more natural than asking for
> the Nth previous commit?

That's the one thing I still prefer to use gitk for.  Everyting else is
much easier to do right in Emacs with magit.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: git apologia

[Yuri Khan]

On Tue, Nov 18, 2014 at 12:55 AM, Achim Gratz <Stromeko@nexgo.de> wrote:

> Eli Zaretskii writes:
>
>> When I pull from upstream, I almost always look at the log summary
>> lines of the last dozen commits, and then frequently examine one or
>> more of those in detail.  So I need a quick and convenient method of
>> doing "git show" or its equivalent without the need to type the 7 hex
>> characters of the SHA1 checksum.  What's more natural than asking for
>> the Nth previous commit?
>
> That's the one thing I still prefer to use gitk for.  Everyting else is
> much easier to do right in Emacs with magit.

Why not also read commits from the magit log? (Full disclosure: I like
gitk too, for its ability to highlight commits touching one or more
selected files.)

Re: git apologia

[Thien-Thi Nguyen]

[-- Attachment #1.1: Type: text/plain, Size: 334 bytes --]

() Eli Zaretskii <eliz@gnu.org>
() Mon, 17 Nov 2014 18:41:50 +0200

   What's more natural than asking for
   the Nth previous commit?

Personally, i use ‘git-show-branch’ and ‘more-vc-git-show’
(sample output and definitions attached) and additionally
bind ‘C-c C-s’ to the latter in compilation mode buffers.


[-- Attachment #1.2: buffer w/ ‘git-show-branch’ output --]
[-- Type: text/plain, Size: 700 bytes --]

Directory: ~/build/GNU/guile-sdl/

! [ack] Release: 0.5.1
 ! [p] Fix typo: Spell "compatib..." correctly!
  ! [q] Fix typo: Spell "compatib..." correctly!
   * [q-fix-k2c] also pass ‘DEFS’ and ‘SDL_CFLAGS’ to k2c, via new var ‘cppopts’
    ! [z-gfx-font] Add ‘set-font!’ and ‘builtin-font’.
-----
   *  [q-fix-k2c] also pass ‘DEFS’ and ‘SDL_CFLAGS’ to k2c, via new var ‘cppopts’
   *  [q-fix-k2c^] make k2c handle command-line ‘-- CFLAGS’
   *  [q-fix-k2c~2] bootstrap w/ Guile-BAUX module ‘minus-i-dirs’
 ++*  [p] Fix typo: Spell "compatib..." correctly!
    + [z-gfx-font] Add ‘set-font!’ and ‘builtin-font’.
+++*+ [ack] Release: 0.5.1

[-- Attachment #1.3: git-show-branch.el --]
[-- Type: application/emacs-lisp, Size: 5004 bytes --]

[-- Attachment #1.4: more-vc.el --]
[-- Type: application/emacs-lisp, Size: 10740 bytes --]

[-- Attachment #1.5: Type: text/plain, Size: 1033 bytes --]


This way i don't need to count anything and stuff before
the earliest branch (in the example, ‘ack’) is never shown
to begin w/; instead, i move point to a ref (e.g., branch
name in square braces, or SHA1) and type ‘C-c C-s’.
That's most natural to me.  The compilation mode support
is to be able to likewise type ‘C-s C-s’ in *compilation*
on arbitrary shell command output (e.g., "git stash list"
or "git log --oneline -42").

The crux is func ‘more-vc-ref-at-point’, which could stand
to be improved, surely...

Anyway, i find "git log" to be only marginally useful (see
my previous grumblings re ChangeLog grepping) but that
will probably change, seeing where things are headed.
Nonetheless, i don't think manually counting commits will
ever be part of my workflow.

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: git apologia

[John Yates]

[-- Attachment #1: Type: text/plain, Size: 371 bytes --]

On Tue, Nov 18, 2014 at 3:58 AM, Thien-Thi Nguyen <ttn@gnu.org> wrote:

> Personally, i use ‘git-show-branch’ and ‘more-vc-git-show’
>

These look interesting so I would like to take them out for a spin.
git-show-branch requires set-keys and file-contents-to-sexp.  Are
these available somewhere on the web?  Or can I get you send
me copies? tia - /john

[-- Attachment #2: Type: text/html, Size: 712 bytes --]

Re: git apologia

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 564 bytes --]

() John Yates <john@yates-sheets.org>
() Tue, 18 Nov 2014 08:53:49 -0500

   set-keys and file-contents-to-sexp.
   Are these available somewhere on the web?

See <http://www.gnuvola.org/software/personal-elisp/>.
The last release was in 2008 and is probably broken under
newer Emacs versions.  Those funcs are simple, though.

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: git apologia

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> What's more natural than asking for the Nth previous commit?

In a DAG it's ambigous.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: git apologia

[Barry Warsaw]

[-- Attachment #1: Type: text/plain, Size: 821 bytes --]

On Nov 18, 2014, at 10:39 AM, Andreas Schwab wrote:

>Eli Zaretskii <eliz@gnu.org> writes:
>
>> What's more natural than asking for the Nth previous commit?
>
>In a DAG it's ambigous.

I think it's more nuanced than that.  Very often in practice commits happen
linearly and in those cases, it's unambiguous.  When merging in feature
branches and such, then yes, technically the multiple parents results in
ambiguity.  Even so, a first-parent default would in practice usually give you
the answer you want.  You can almost always ignore the details of the merge
(of course, with command line overrides for when you need to delve deeper).

Bazaar uses a first-parent default because it promotes a "main line of
development" work flow, which is almost always what you (well, *I* :) want.

Cheers,
-Barry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Sergey Organov]

Eli Zaretskii <eliz@gnu.org> writes:

[...]

> 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:

| sed -e 's/Git/Emacs/g' | sed -e 's/VCS/Editor/g'

and the result still holds. It's just that Git and Emacs have better
ways of doing things than anything else out there ;-)

-- 
Sergey.

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

[Eli Zaretskii]

> From: Sergey Organov <sorganov@gmail.com>
> Date: Mon, 17 Nov 2014 15:38:13 +0300
> 
> > 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:
> 
> | sed -e 's/Git/Emacs/g' | sed -e 's/VCS/Editor/g'
> 
> and the result still holds. It's just that Git and Emacs have better
> ways of doing things than anything else out there ;-)

I use Emacs for more than 20 years.  If I used Git for so long, it's
highly probable that the above would have never been written.

Moreover, the first programmer's editor I ever used, before I switched
to Emacs, was an Emacs clone, so I never needed to unlearn anything
even when I started using Emacs.

As for nomenclature, Emacs is different because it did a
ground-breaking job: there was no "prior art" to follow at the time.
Git, OTOH, could have used the widely adopted terminology and
semantics, but instead deliberately chose not to.  Doing things better
doesn't need a drastic change in terminology.

And I don't want to even start comparing the quality of the Emacs
documentation with that of Git.

So no, the result doesn't hold, not for me anyway.

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

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

> Git, OTOH, could have used the widely adopted terminology and
> semantics, but instead deliberately chose not to.  Doing things better
> doesn't need a drastic change in terminology.

Git was created in order to enable workflows as efficient than those
developed while using BitKeeper whose license for use by Linux
developers had been pulled.

To be on the safe legal side, one design metric was to be quite
different from BitKeeper.  Another design metric was high efficiency.
A prototype was running within weeks, basically consisting of several
low-level commands.  Yet another design metric was to avoid falling into
any of the traps of the current centralized version control systems.

So the idea was to be really different from Bitkeeper (which was
considered a good system but must not be copied) and really different
from established centralized VCS systems (which were considered bad
systems to the degree that Torvalds said something like the SVN slogan
"a better CVS" was sort of an oxymoron since he considered "everything
CVS should have been" would be more or less "dead, buried, and
forgotten").  In practice, I don't feel that the "really different"
angle is all that strong.  Still, when trying to search for pillars one
can rely on, this may prove irritating.

Git was heavily used and developed before anybody could have tried
retrofitting an overarching design and philosophy over what happened to
work efficiently.  Restraining the toolbox the first generation coders
would have met disapproval (of the "changing horses in midstream" kind),
and it would also likely have been considered hubris.

So Git is more or less defined by its mechanisms rather than its
concepts.  Changing that would likely prove tricky.  There are several
toolsets, graphical or command line, facilitating/favoring particular
workflows.  Emacs has its own chance of supporting particular workflows
via what it makes available as part of PVCS and/or VC.

-- 
David Kastrup

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

[Sergey Organov]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Sergey Organov <sorganov@gmail.com>
>> Date: Mon, 17 Nov 2014 15:38:13 +0300
>> 
>> > 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:
>> 
>> | sed -e 's/Git/Emacs/g' | sed -e 's/VCS/Editor/g'
>> 
>> and the result still holds. It's just that Git and Emacs have better
>> ways of doing things than anything else out there ;-)
>
> I use Emacs for more than 20 years.  If I used Git for so long, it's
> highly probable that the above would have never been written.
>
> Moreover, the first programmer's editor I ever used, before I switched
> to Emacs, was an Emacs clone, so I never needed to unlearn anything
> even when I started using Emacs.
>
> As for nomenclature, Emacs is different because it did a
> ground-breaking job: there was no "prior art" to follow at the time.
> Git, OTOH, could have used the widely adopted terminology and
> semantics, but instead deliberately chose not to.  Doing things better
> doesn't need a drastic change in terminology.

I've used other editors before Emacs, and I've used other VCSes before
Git. What I can say is that both tools have a nice property: the more
you use them, the more you like them... well, at least so far... Other
similar tools I used started to be annoyingly limited for me rather
soon.

> And I don't want to even start comparing the quality of the Emacs
> documentation with that of Git.

Git is young and it gets better. Give Git at least half of Emacs
life-time...

-- 
Sergey.

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

[Glenn Morris]

Eli Zaretskii wrote:

> And I don't want to even start comparing the quality of the Emacs
> documentation with that of Git.

http://git-man-page-generator.lokaltog.net/

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

[Alan Mackenzie]

Hello, Glenn.

On Mon, Nov 17, 2014 at 10:29:53PM -0500, Glenn Morris wrote:
> Eli Zaretskii wrote:

> > And I don't want to even start comparing the quality of the Emacs
> > documentation with that of Git.

> http://git-man-page-generator.lokaltog.net/

Ha!  That is good!

Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> This "confusion" I still don't get.  Git semantics are singly-linked
> list semantics: 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?

A list is a high-level concept.  This high-level concept as a sequence
of items does not result in semantics like the support of shared tails.
Indeed, only singly-forward-linked lists with individually
reference-managed list members support these particular semantics
seamlessly: they are not "list semantics" but are emergent semantics
from a very particular set of list implementations.

The Git reference system can be described in terms of non-circular
versions of LISP lists.  But in reality we are not talking about "list
semantics" here.  What you call "list semantics" are "finite directed
graph" semantics, and Git uses the subset of "finite directed acyclical
graph" semantics.

That LISP uses directed acyclical graphs for representing finite lists
is an implementation detail, not a high-level description of what lists
are, namely a sequence of items.  And LISP lists are a subset, since
they are either a _finite_ or a terminally cyclical sequence of items.
LISP cannot represent things like the list of natural numbers.

So LISP's _implementation_ of lists can be mapped somewhat comfortably
to Git's use of finite directed acyclical graphs.  That's an
isomorphism.  Which is nice if you want to map a Git repository to Emacs
data structures.

It does not mean that Git uses "list semantics", however.  Nor does it
mean that Git's behavior can well be described or even implemented in
terms of _lists_ rather than of a particularly organized tree of conses.

Try, for example, describing the structure of a Git repository in terms
of a C++ STL list type rather than of LISP "lists".  Doesn't work.

The talk about "list semantics" is a red herring even though any
traversal along the edges of a finite directed acyclical graph ends up
being a list.

-- 
David Kastrup

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

[Stephen J. Turnbull]

David Kastrup writes:

 > > What's so hard about list semantics for an Emacs developer?
 > 
 > A list is a high-level concept.

Jeez, David, this is an *Emacs* ML, you could at least assume that the
semantics of Emacs lists (built of conses, and including "dotted"
lists) are meant.  As Eli did.