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

[David Kastrup]

Eli Zaretskii <address@hidden> 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 @address@hidden is more to type and
>     remember; the similar @address@hidden has a subtly different meaning.

Not subtle at all, actually.  @address@hidden 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 "@address@hidden" 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 address@hidden 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