git is screwed

git is screwed

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I committed some changes using C-x v v in vc-dir.
Something went wrong with lisp/ChangeLog.

It appears that my change log entries went into an old version of that
file; I don't know why this happened, since I wrote them today after
doing 'git pull'.

After this, I did 'git pull' again, and it said there was a merge
conflict in lisp/ChangeLpg.  A lot of text appears to be missing from
the file.  It said, "fix conflicts and then commit the result."

I edited lisp/ChangeLog and tried to commit it with C-x v v.
That gave me the error message

  fatal: cannot do a partial commit during a merge.

I am now stuck.  I don't know what a "merge" is; it is certainly
nothing I asked to do.

How can I get this unwedged?

Is my change to the default value of browse-url-firefox-program
visible in browse-url.el?  It should try icecat first.

My previous use of git is limited to getting the Emacs sources
to build them.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: git is screwed

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

> I edited lisp/ChangeLog and tried to commit it with C-x v v.
> That gave me the error message
>
>   fatal: cannot do a partial commit during a merge.
>
> I am now stuck.  I don't know what a "merge" is; it is certainly
> nothing I asked to do.
>
> How can I get this unwedged?

Try 'git merge --abort'.

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 is screwed

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Try 'git merge --abort'.

Thanks, but I got

error: Entry 'lisp/ChangeLog' not uptodate. Cannot merge.
fatal: Could not reset index file to revision 'HEAD'.

I also tried  git merge --abort lisp/ChangeLog
and got the same error.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: git is screwed

[Sam Gwydir]

-- Bringing us back to the mailing list.

On 03/22, Richard Stallman wrote:

> What OTHER effects does it have?  I don't dare try it unless I know
> it won't screw me some other way.

As far as I know, none. 'git pull' is basically an alias for 'git
fetch; git merge'. Many git users never use pull and always fetch
separately for more control.

The reason it puts you into an intermediate merge state is in order to
not screw you. If you run 'git status' you can see the current state of
your local branch.

> What does "pushing" mean?

Pushing merges your local branch with the remote branch (Savannah). 'svn
commit' for git would be 'git commit && git push'.

Take a look at this page[1] if you know svn, it lists the analogous
commands.

> I assumed that C-x v v was installing my changes.

From info: 

  ...VC supports many common Git operations, but others, such as
  repository syncing, must be done from the command line.

I don't use vc.el, but from some quick testing it appears it only
commits. You have to push separately.

Many people, myself included, use Magit[2] to interact with git through
emacs. It will simplify your life. There is a package in MELPA if you
are interested.

Sam Gwydir.

Footnotes:

[1] https://git.wiki.kernel.org/index.php/GitSvnCrashCourse
[2] https://github.com/magit/magit

-- 
Sam Gwydir
Texas A&M University
+1 713 446 0367
sam@samgwydir.com

Re: git is screwed

[Harald Hanche-Olsen]

Sam Gwydir wrote:
> As far as I know, none. 'git pull' is basically an alias for 'git
> fetch; git merge'. Many git users never use pull and always fetch
> separately for more control.

git pull --ff-only
is pretty safe. I have it aliased to up (short for update):

; git config --global alias.up 'git pull --ff-only'
; git help up
`git up' is aliased to `pull --ff-only'

It will abort the merge if it can't be done using fast-forward.
(In other words, if the local branch has diverged from the remote.)

– Harald

Re: git is screwed

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It will abort the merge if it can't be done using fast-forward.
  > (In other words, if the local branch has diverged from the remote.)

I understand that.  What should I do when that occurs?

Can someone tell me a full recipe for how to repair lisp/ChangeLog
(perhaps, merge it by hand) and how to get the new version into
the real repository?


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: git is screwed

[Harald Hanche-Olsen]

Richard Stallman wrote:
>    >  It will abort the merge if it can't be done using fast-forward.
>    >  (In other words, if the local branch has diverged from the remote.)
>
> I understand that.  What should I do when that occurs?

In general? I would probably stash the working tree (and index) using 
“git stash”, then try “git pull --ff-only” again. If that succeeds, I 
would try to reapply the stashed state on top of the new head with “git 
stash pop”.

> Can someone tell me a full recipe for how to repair lisp/ChangeLog
> (perhaps, merge it by hand) and how to get the new version into
> the real repository?

I think it might be useful if you posted the result of running “git 
status -s” so we can assess the damage.

If it were me, I would make sure to copy all changed files into a safe 
place outside the git working tree to minimise any fallout from a failed 
recovery attempt. Then I might try a “git reset --hard” and try to 
restore the working tree to a sane state based on what I saved earlier. 
But please note that I have never found myself in the situation you're 
in, so it is dangerous to rely on my advice. Please do post the output 
of git status -s before doing anything rash.

– Harald

Re: git is screwed

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I think it might be useful if you posted the result of running “git 
  > status -s” so we can assess the damage.

Here it is.  I can only guess what the flags mean, but if 'M' means it
is modified on this machine, I am very surprised -- I never touched
most of those files.

M  .gitattributes
M  CONTRIBUTE
M  ChangeLog
D  README.xwidget
M  admin/ChangeLog
M  admin/MAINTAINERS
M  admin/admin.el
M  admin/authors.el
M  admin/notes/repo
M  configure.ac
M  doc/emacs/ChangeLog
M  doc/emacs/ack.texi
M  doc/emacs/basic.texi
M  doc/emacs/buffers.texi
M  doc/emacs/cmdargs.texi
M  doc/emacs/custom.texi
M  doc/emacs/display.texi
M  doc/emacs/frames.texi
M  doc/emacs/killing.texi
M  doc/emacs/mini.texi
M  doc/emacs/misc.texi
M  doc/emacs/msdos-xtra.texi
M  doc/emacs/msdos.texi
M  doc/emacs/mule.texi
M  doc/emacs/programs.texi
M  doc/emacs/text.texi
M  doc/emacs/trouble.texi
M  doc/lispintro/emacs-lisp-intro.texi
M  doc/lispref/ChangeLog
M  doc/lispref/commands.texi
M  doc/lispref/control.texi
M  doc/lispref/display.texi
M  doc/lispref/elisp.texi
M  doc/lispref/frames.texi
M  doc/lispref/functions.texi
M  doc/lispref/internals.texi
M  doc/lispref/loading.texi
M  doc/lispref/minibuf.texi
M  doc/lispref/numbers.texi
M  doc/lispref/objects.texi
M  doc/lispref/os.texi
M  doc/lispref/positions.texi
M  doc/lispref/processes.texi
M  doc/lispref/searching.texi
M  doc/lispref/sequences.texi
M  doc/lispref/streams.texi
M  doc/lispref/text.texi
M  doc/misc/ChangeLog
M  doc/misc/auth.texi
M  doc/misc/calc.texi
M  doc/misc/cc-mode.texi
M  doc/misc/cl.texi
M  doc/misc/efaq-w32.texi
M  doc/misc/efaq.texi
M  doc/misc/eieio.texi
M  doc/misc/erc.texi
M  doc/misc/eshell.texi
M  doc/misc/eww.texi
M  doc/misc/gnus.texi
M  doc/misc/htmlfontify.texi
M  doc/misc/idlwave.texi
M  doc/misc/ido.texi
M  doc/misc/newsticker.texi
M  doc/misc/org.texi
M  doc/misc/pgg.texi
M  doc/misc/reftex.texi
M  doc/misc/texinfo.tex
M  doc/misc/todo-mode.texi
M  doc/misc/tramp.texi
M  doc/misc/trampver.texi
M  doc/misc/vhdl-mode.texi
M  doc/misc/vip.texi
M  doc/misc/viper.texi
M  doc/misc/woman.texi
M  etc/AUTHORS
M  etc/ChangeLog
M  etc/GNUS-NEWS
M  etc/NEWS
M  etc/NEWS.24
M  etc/TODO
M  leim/ChangeLog
M  leim/Makefile.in
M  lib-src/ChangeLog
M  lib-src/Makefile.in
M  lib-src/emacsclient.c
M  lib-src/etags.c
M  lib-src/make-docfile.c
M  lib-src/movemail.c
M  lib/dirent.in.h
A  lib/dirfd.c
M  lib/fdopendir.c
M  lib/getdtablesize.c
M  lib/getopt.c
M  lib/gnulib.mk
M  lib/signal.in.h
M  lib/tempname.c
M  lib/tempname.h
MM lisp/ChangeLog
M  lisp/ChangeLog.16
M  lisp/Makefile.in
M  lisp/autorevert.el
M  lisp/battery.el
M  lisp/bindings.el
M  lisp/calendar/solar.el
M  lisp/calendar/todo-mode.el
M  lisp/cedet/ChangeLog
M  lisp/cedet/ede.el
M  lisp/cedet/ede/auto.el
M  lisp/cedet/ede/base.el
M  lisp/cedet/ede/config.el
M  lisp/cedet/ede/cpp-root.el
M  lisp/cedet/ede/custom.el
M  lisp/cedet/ede/emacs.el
M  lisp/cedet/ede/files.el
M  lisp/cedet/ede/generic.el
M  lisp/cedet/ede/linux.el
M  lisp/cedet/ede/locate.el
M  lisp/cedet/ede/pconf.el
M  lisp/cedet/ede/pmake.el
M  lisp/cedet/ede/proj-archive.el
M  lisp/cedet/ede/proj-aux.el
M  lisp/cedet/ede/proj-comp.el
M  lisp/cedet/ede/proj-elisp.el
M  lisp/cedet/ede/proj-info.el
M  lisp/cedet/ede/proj-misc.el
M  lisp/cedet/ede/proj-obj.el
M  lisp/cedet/ede/proj-prog.el
M  lisp/cedet/ede/proj-scheme.el
M  lisp/cedet/ede/proj-shared.el
M  lisp/cedet/ede/proj.el
M  lisp/cedet/ede/project-am.el
M  lisp/cedet/ede/shell.el
M  lisp/cedet/ede/simple.el
M  lisp/cedet/ede/source.el
M  lisp/cedet/ede/speedbar.el
M  lisp/cedet/ede/util.el
M  lisp/cedet/semantic/analyze.el
M  lisp/cedet/semantic/analyze/refs.el
M  lisp/cedet/semantic/bovine/debug.el
M  lisp/cedet/semantic/complete.el
M  lisp/cedet/semantic/db-ebrowse.el
M  lisp/cedet/semantic/db-el.el
M  lisp/cedet/semantic/db-file.el
M  lisp/cedet/semantic/db-find.el
M  lisp/cedet/semantic/db-global.el
M  lisp/cedet/semantic/db-javascript.el
M  lisp/cedet/semantic/db-ref.el
M  lisp/cedet/semantic/db-typecache.el
M  lisp/cedet/semantic/db.el
M  lisp/cedet/semantic/debug.el
M  lisp/cedet/semantic/decorate/include.el
M  lisp/cedet/semantic/doc.el
M  lisp/cedet/semantic/ede-grammar.el
M  lisp/cedet/semantic/ia-sb.el
M  lisp/cedet/semantic/mru-bookmark.el
M  lisp/cedet/semantic/scope.el
M  lisp/cedet/semantic/symref.el
M  lisp/cedet/semantic/symref/cscope.el
M  lisp/cedet/semantic/symref/global.el
M  lisp/cedet/semantic/symref/grep.el
M  lisp/cedet/semantic/symref/idutils.el
M  lisp/cedet/srecode/compile.el
M  lisp/cedet/srecode/dictionary.el
M  lisp/cedet/srecode/document.el
M  lisp/cedet/srecode/extract.el
M  lisp/cedet/srecode/fields.el
M  lisp/cedet/srecode/find.el
M  lisp/cedet/srecode/insert.el
M  lisp/cedet/srecode/map.el
M  lisp/cedet/srecode/semantic.el
M  lisp/cedet/srecode/table.el
M  lisp/comint.el
M  lisp/delsel.el
M  lisp/desktop.el
M  lisp/dired.el
M  lisp/doc-view.el
M  lisp/dom.el
M  lisp/emacs-lisp/byte-opt.el
M  lisp/emacs-lisp/byte-run.el
M  lisp/emacs-lisp/bytecomp.el
M  lisp/emacs-lisp/cconv.el
M  lisp/emacs-lisp/check-declare.el
M  lisp/emacs-lisp/checkdoc.el
M  lisp/emacs-lisp/cl-generic.el
M  lisp/emacs-lisp/cl-indent.el
M  lisp/emacs-lisp/cl-lib.el
M  lisp/emacs-lisp/cl-macs.el
M  lisp/emacs-lisp/cl-preloaded.el
M  lisp/emacs-lisp/debug.el
M  lisp/emacs-lisp/easy-mmode.el
M  lisp/emacs-lisp/edebug.el
M  lisp/emacs-lisp/eieio-base.el
M  lisp/emacs-lisp/eieio-compat.el
M  lisp/emacs-lisp/eieio-core.el
M  lisp/emacs-lisp/eieio-custom.el
M  lisp/emacs-lisp/eieio-datadebug.el
M  lisp/emacs-lisp/eieio-opt.el
M  lisp/emacs-lisp/eieio.el
A  lisp/emacs-lisp/generator.el
M  lisp/emacs-lisp/gv.el
M  lisp/emacs-lisp/lisp-mode.el
M  lisp/emacs-lisp/lisp.el
M  lisp/emacs-lisp/macroexp.el
M  lisp/emacs-lisp/package-x.el
M  lisp/emacs-lisp/package.el
M  lisp/emacs-lisp/pcase.el
M  lisp/emacs-lisp/seq.el
M  lisp/emacs-lisp/smie.el
D  lisp/emacs-parallel/README.org
D  lisp/emacs-parallel/parallel-remote.el
D  lisp/emacs-parallel/parallel-xwidget.el
D  lisp/emacs-parallel/parallel.el
M  lisp/emulation/viper-cmd.el
M  lisp/emulation/viper-init.el
M  lisp/emulation/viper-keym.el
M  lisp/erc/ChangeLog
M  lisp/erc/erc-spelling.el
M  lisp/erc/erc.el
M  lisp/eshell/em-hist.el
M  lisp/eshell/em-pred.el
M  lisp/eshell/esh-mode.el
M  lisp/facemenu.el
M  lisp/faces.el
M  lisp/filecache.el
M  lisp/files.el
M  lisp/font-lock.el
M  lisp/frame.el
M  lisp/frameset.el
M  lisp/gnus/ChangeLog
M  lisp/gnus/gnus-art.el
M  lisp/gnus/gnus-int.el
M  lisp/gnus/gnus-msg.el
M  lisp/gnus/gnus-notifications.el
M  lisp/gnus/gnus-registry.el
M  lisp/gnus/gnus-start.el
M  lisp/gnus/gnus-sum.el
M  lisp/gnus/mail-source.el
M  lisp/gnus/mailcap.el
M  lisp/gnus/message.el
M  lisp/gnus/mm-decode.el
M  lisp/gnus/mm-util.el
M  lisp/gnus/mm-view.el
M  lisp/gnus/nnimap.el
M  lisp/gnus/nnir.el
M  lisp/gnus/nnmail.el
M  lisp/gnus/registry.el
M  lisp/help-fns.el
M  lisp/help-mode.el
M  lisp/help.el
M  lisp/hi-lock.el
M  lisp/ido.el
M  lisp/image-mode.el
M  lisp/info-look.el
M  lisp/international/fontset.el
M  lisp/international/quail.el
M  lisp/isearchb.el
M  lisp/json.el
M  lisp/ldefs-boot.el
M  lisp/leim/quail/hangul.el
M  lisp/mail/rmail.el
M  lisp/mail/rmailmm.el
M  lisp/mail/rmailsum.el
M  lisp/menu-bar.el
M  lisp/misearch.el
M  lisp/mouse.el
M  lisp/net/browse-url.el
M  lisp/net/dbus.el
M  lisp/net/eudcb-bbdb.el
M  lisp/net/eudcb-ldap.el
M  lisp/net/eww.el
M  lisp/net/ldap.el
M  lisp/net/network-stream.el
R  lisp/gnus/rfc2104.el -> lisp/net/rfc2104.el
A  lisp/net/sasl-scram-rfc.el
M  lisp/net/sasl.el
M  lisp/net/shr.el
M  lisp/net/tramp-adb.el
M  lisp/net/tramp-cache.el
M  lisp/net/tramp-gvfs.el
M  lisp/net/tramp-sh.el
M  lisp/net/tramp-smb.el
M  lisp/net/tramp.el
M  lisp/net/trampver.el
M  lisp/newcomment.el
M  lisp/obsolete/iswitchb.el
M  lisp/org/ChangeLog
M  lisp/outline.el
M  lisp/play/gamegrid.el
M  lisp/progmodes/cc-engine.el
M  lisp/progmodes/cc-mode.el
M  lisp/progmodes/cperl-mode.el
M  lisp/progmodes/elisp-mode.el
M  lisp/progmodes/f90.el
M  lisp/progmodes/gdb-mi.el
M  lisp/progmodes/gud.el
M  lisp/progmodes/js.el
M  lisp/progmodes/python.el
M  lisp/progmodes/ruby-mode.el
M  lisp/progmodes/sql.el
M  lisp/progmodes/verilog-mode.el
M  lisp/progmodes/vhdl-mode.el
M  lisp/progmodes/xref.el
M  lisp/rect.el
M  lisp/register.el
M  lisp/replace.el
M  lisp/server.el
M  lisp/simple.el
M  lisp/startup.el
M  lisp/subr.el
M  lisp/textmodes/artist.el
M  lisp/textmodes/css-mode.el
M  lisp/textmodes/flyspell.el
M  lisp/textmodes/ispell.el
M  lisp/textmodes/reftex-vars.el
M  lisp/textmodes/text-mode.el
M  lisp/url/ChangeLog
M  lisp/url/url-handlers.el
M  lisp/vc/vc-bzr.el
M  lisp/vc/vc-cvs.el
M  lisp/vc/vc-git.el
M  lisp/vc/vc-hg.el
M  lisp/vc/vc-hooks.el
M  lisp/vc/vc-mtn.el
M  lisp/vc/vc-rcs.el
M  lisp/vc/vc-sccs.el
M  lisp/vc/vc-src.el
M  lisp/vc/vc-svn.el
M  lisp/vc/vc.el
M  lisp/w32-vars.el
M  lisp/widget.el
M  lisp/windmove.el
M  lisp/window.el
M  lisp/winner.el
D  lisp/xwidget.el
M  lwlib/ChangeLog
M  lwlib/xlwmenu.c
A  m4/dirfd.m4
M  m4/dup2.m4
M  m4/fcntl.m4
M  m4/getdtablesize.m4
M  m4/gnulib-comp.m4
M  nt/ChangeLog
M  nt/INSTALL
M  nt/cmdproxy.c
M  nt/inc/ms-w32.h
M  src/ChangeLog
M  src/Makefile.in
M  src/alloc.c
M  src/bidi.c
M  src/buffer.c
M  src/bytecode.c
M  src/callint.c
M  src/callproc.c
M  src/character.c
M  src/character.h
M  src/charset.c
M  src/coding.c
M  src/data.c
M  src/dispextern.h
M  src/dispnew.c
M  src/editfns.c
M  src/emacs.c
M  src/emacsgtkfixed.c
M  src/emacsgtkfixed.h
M  src/eval.c
M  src/fileio.c
M  src/fns.c
M  src/font.c
M  src/frame.c
M  src/frame.h
M  src/ftfont.c
M  src/gtkutil.c
M  src/indent.c
M  src/intervals.h
M  src/keyboard.c
M  src/keymap.c
M  src/lisp.h
M  src/lread.c
M  src/menu.c
M  src/minibuf.c
M  src/nsfns.m
M  src/print.c
M  src/regex.c
M  src/search.c
M  src/sysdep.c
M  src/sysstdio.h
M  src/systime.h
M  src/termhooks.h
M  src/textprop.c
M  src/w32.c
M  src/w32fns.c
M  src/w32font.c
M  src/w32inevt.c
M  src/w32term.c
M  src/widget.c
M  src/window.c
M  src/xdisp.c
M  src/xfaces.c
M  src/xfns.c
M  src/xfont.c
M  src/xmenu.c
M  src/xml.c
M  src/xterm.c
M  src/xterm.h
D  src/xwidget.c
D  src/xwidget.h
M  test/ChangeLog
M  test/automated/cl-lib-tests.el
M  test/automated/eieio-test-methodinvoke.el
M  test/automated/eieio-test-persist.el
M  test/automated/eieio-tests.el
M  test/automated/f90.el
A  test/automated/finalizer-tests.el
A  test/automated/generator-tests.el
M  test/automated/package-test.el
M  test/automated/python-tests.el
A  test/automated/sasl-scram-rfc-tests.el
M  test/automated/seq-tests.el
M  test/automated/tramp-tests.el
M  test/automated/vc-tests.el
D  test/automated/xwidget-tests.el
M  test/cedet/srecode-tests.el
M  test/indent/Makefile
A  test/indent/js-indent-init-dynamic.js
A  test/indent/js-indent-init-t.js
M  test/indent/js.js
M  test/indent/ruby.rb
D  test/xwidget-test-manual.el

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: git is screwed

[Harald Hanche-Olsen]

Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>    >  I think it might be useful if you posted the result of running “git
>    >  status -s” so we can assess the damage.
>
> Here it is.  I can only guess what the flags mean,

You can run “git help status” and read what it says under the heading 
“Short Format”.

 > but if 'M' means it
> is modified on this machine, I am very surprised -- I never touched
> most of those files.

The vast majority have M in the first column and a space in the second. 
That means they are modified in the index (uh, staging area is the 
modern name for it). They will be the result of the incomplete merge:
Most of them are files that have been modified in the remote repository 
but not locally. The Ds have been deleted, and the As have been added.

> M  .gitattributes
> M  CONTRIBUTE
 > […]

The only file with a non-blank second column is here:

> MM lisp/ChangeLog

That's your merge conflict.

I have to go now, no time for the next couple hours. But perhaps someone 
else will give you advice.

Perhaps it is useful if you also run these commands and report the output:

git show-ref HEAD
git show-ref master

The latter assuming you're on the master branch. Otherwise, replace 
“master” by emacs-24 or whatever branch you're on.

– Harald

Re: git is screwed

[Harald Hanche-Olsen]

Harald Hanche-Olsen wrote:
> The vast majority have M in the first column and a space in the second.
> That means they are modified in the index (uh, staging area is the
> modern name for it). They will be the result of the incomplete merge:
> Most of them are files that have been modified in the remote repository
> but not locally. The Ds have been deleted, and the As have been added.

I could have added that this means those files marked M will be the 
result of successfully merging your changes with those in the remote. 
Think of it as the result piping diff output into patch. Or they are 
just the ones changed remotely, if you have made no local changes.

> I have to go now, no time for the next couple hours. But perhaps someone
> else will give you advice.

But now I *really* have to go.

– Harald

Re: git is screwed

[Steinar Bang]

>>>>> Harald Hanche-Olsen <hanche@math.ntnu.no>:

>> MM lisp/ChangeLog

> That's your merge conflict.

> I have to go now, no time for the next couple hours. But perhaps
> someone else will give you advice.

What I would do here is to open the ChangeLog in emacs and look for the
conflict markers (search for "<<" (without the quotes)) and see if they
make sense to me.  I then manually edit the result to what I want (I
remove the conflict markers, then either pick one of the alternatives,
both alternatives, or make a manual merge of the two, depending on what
the conflict is).

Once I'm satisfied with the results, I stage the ChangeLog file for the
merge commit:
 git add lisp/ChangeLog

Right now I've told git that I've seen the conflict and have manually
resolved it, and git will complete the merge when I give the following
command:
 git commit

(and as I said in a different post: I usually do this kind of merge
conflict resolution from magit)

Re: git is screwed

[Stefan Monnier]

> What I would do here is to open the ChangeLog in emacs and look for the
> conflict markers (search for "<<" (without the quotes)) and see if they
> make sense to me.  I then manually edit the result to what I want (I
> remove the conflict markers, then either pick one of the alternatives,
> both alternatives, or make a manual merge of the two, depending on what
> the conflict is).

> Once I'm satisfied with the results, I stage the ChangeLog file for the
> merge commit:
>  git add lisp/ChangeLog

And if all went according to plan, Emacs-25 would have already done this
"git add" when you saved the file after removing the conflict markers.


        Stefan

Re: git is screwed

[Eli Zaretskii]

> From: Steinar Bang <sb@dod.no>
> Date: Thu, 26 Mar 2015 13:21:04 +0100
> 
> What I would do here is to open the ChangeLog in emacs and look for the
> conflict markers (search for "<<" (without the quotes)) and see if they
> make sense to me.  I then manually edit the result to what I want (I
> remove the conflict markers, then either pick one of the alternatives,
> both alternatives, or make a manual merge of the two, depending on what
> the conflict is).
> 
> Once I'm satisfied with the results, I stage the ChangeLog file for the
> merge commit:
>  git add lisp/ChangeLog
> 
> Right now I've told git that I've seen the conflict and have manually
> resolved it, and git will complete the merge when I give the following
> command:
>  git commit
> 
> (and as I said in a different post: I usually do this kind of merge
> conflict resolution from magit)

What's wrong with smerge-mode?  It should kick in automatically when
you have conflict markers, and also invoke "git add" automatically for
every file saved after resolving all of its conflicts.

Re: git is screwed

[Steinar Bang]

>>>>> Eli Zaretskii <eliz@gnu.org>:

> What's wrong with smerge-mode?

I haven't tried it yet.  I just heard about it 24 days ago (the thread
"smerge-mode is fantastic, but it annoys me").

> It should kick in automatically when you have conflict markers,

Um... since when...?  24.4?  Or git master HEAD?

> and also invoke "git add" automatically for every file saved after
> resolving all of its conflicts.

Is that configurable?  It sounds like a step I would like to control
myself.

Re: git is screwed

[Eli Zaretskii]

> From: Steinar Bang <sb@dod.no>
> Date: Thu, 26 Mar 2015 20:02:58 +0100
> 
> > It should kick in automatically when you have conflict markers,
> 
> Um... since when...?  24.4?  Or git master HEAD?

It needs support from the VC backend.  It was working with bzr for a
long time, but vc-git only has that support on master.

> > and also invoke "git add" automatically for every file saved after
> > resolving all of its conflicts.
> 
> Is that configurable?  It sounds like a step I would like to control
> myself.

It's a minor mode, so of course it's configurable: just switch it off.
Or remove its hook from find-file-hook.  (Not that I understand why
would you want to.)

Re: git is screwed

[Stefan Monnier]

>> Is that configurable?

Not currently, no.

>> It sounds like a step I would like to control myself.

There's a (recentish) bug report about that, indeed.

> It's a minor mode, so of course it's configurable: just switch it off.

The "git add" part is independent from smerge-mode (tho they're linked
by the fact that they both depend on the VC backend being able to
recognize that a file has conflicts).  So turning smerge-mode off won't help.


        Stefan

Re: git is screwed

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Steinar Bang <sb@dod.no>,  emacs-devel@gnu.org
> Date: Thu, 26 Mar 2015 18:34:21 -0400
> 
> > It's a minor mode, so of course it's configurable: just switch it off.
> 
> The "git add" part is independent from smerge-mode (tho they're linked
> by the fact that they both depend on the VC backend being able to
> recognize that a file has conflicts).  So turning smerge-mode off won't help.

It wasn't clear from the question what needs to be configurable.
There was another advice, which you elided, that would disable "git
add" as well.

Re: git is screwed

[Stefan Monnier]

>> > It's a minor mode, so of course it's configurable: just switch it off.
>> The "git add" part is independent from smerge-mode (tho they're linked
>> by the fact that they both depend on the VC backend being able to
>> recognize that a file has conflicts).  So turning smerge-mode off won't help.
> It wasn't clear from the question what needs to be configurable.
> There was another advice, which you elided, that would disable "git
> add" as well.

IIUC removing vc-find-file-hook from find-file-hook would have other
effects beside avoiding the "git add" (IIRC the main one would be to
not auto-enable smerge-mode).

To only skip the "git add", you'd need to

    (remove-hook 'after-save-hook 'vc-git-resolve-when-done 'local)

but this needs to be done after the corresponding `add-hook'.  I haven't
checked, but the following might/should work:

    (add-hook 'find-file-hook
              (lambda ()
                (remove-hook 'after-save-hook 'vc-git-resolve-when-done 'local))
              ;; Put it after VC's vc-find-file-hook.
              'append)


-- Stefan

Re: git is screwed

[Steinar Bang]

>>>>> Eli Zaretskii <eliz@gnu.org>:

> It wasn't clear from the question what needs to be configurable.

I just wanted to switch off the automatic "git add" bit.

Re: git is screwed

[Eli Zaretskii]

> From: Steinar Bang <sb@dod.no>
> Date: Fri, 27 Mar 2015 20:35:09 +0100
> 
> >>>>> Eli Zaretskii <eliz@gnu.org>:
> 
> > It wasn't clear from the question what needs to be configurable.
> 
> I just wanted to switch off the automatic "git add" bit.

Then I wonder why you'd want smerge-mode at all.

Re: git is screwed

[Steinar Bang]

>>>>> Eli Zaretskii <eliz@gnu.org>:

> Then I wonder why you'd want smerge-mode at all.

The "is fantastic" part of the subject of the mentioned thread, makes it
quite possible that I'll try it out when it eventually comes my way.

Maybe I'll love it, maybe I'll hate it, maybe I'll disable the automated
add... who knows...?

The future is full of possibilites.

Re: git is screwed

[Steinar Bang]

>>>>> Eli Zaretskii <eliz@gnu.org>:

>> From: Steinar Bang <sb@dod.no>

>> > It should kick in automatically when you have conflict markers,

>> Um... since when...?  24.4?  Or git master HEAD?

> It needs support from the VC backend.  It was working with bzr for a
> long time, but vc-git only has that support on master.

Ok, it'll be a while until I see it, then.

(Gnus and org comes from git, but my emacs is the newest released
version)

>> Is that configurable?  It sounds like a step I would like to control
>> myself.

> It's a minor mode, so of course it's configurable: just switch it off.
> Or remove its hook from find-file-hook.  (Not that I understand why
> would you want to.)

It's just I like to inspect before I stage.

Force of habit, I guess...

(Another thing is that when I go back to magit it won't have display the
staged file, and it feels like more correct to do 's' to stage the file,
instead of 'g' to refresh magit)

Nothing important in other words.

Re: git is screwed

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Looking at man git-stash

       save [-p|--patch] [--[no-]keep-index] [-u|--include-untracked]
       [-a|--all] [-q|--quiet] [<message>]
           Save your local modifications to a new stash, and run git reset
           --hard to revert them. The <message> part is optional and gives the
           description along with the stashed state. For quickly making a
           snapshot, you can omit both "save" and <message>, but giving only
           <message> does not trigger this action to prevent a misspelled
           subcommand from making an unwanted stash.

That sounds dangerous so I didn't do it yet.  Is that what I should do?

       create
           Create a stash (which is a regular commit object) and return its
           object name, without storing it anywhere in the ref namespace.

I can't make concrete sense of that.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: git is screwed

[John Wiegley]

>>>>> Richard Stallman <rms@gnu.org> writes:

> Looking at man git-stash

>        save [-p|--patch] [--[no-]keep-index] [-u|--include-untracked]
>        [-a|--all] [-q|--quiet] [<message>]
>            Save your local modifications to a new stash, and run git reset
>            --hard to revert them. The <message> part is optional and gives the
>            description along with the stashed state. For quickly making a
>            snapshot, you can omit both "save" and <message>, but giving only
>            <message> does not trigger this action to prevent a misspelled
>            subcommand from making an unwanted stash.

> That sounds dangerous so I didn't do it yet.  Is that what I should do?

Before you do a complex operation (such as a pull when you have both locally
committed changes, and locally uncommitted changes), you can run "git stash"
to safely squirrel away your work.  It sounds dangerous from the man page, but
it's a very safe operation.  I do it regularly.

Then, proceed with your complex operation.  Once you get everything back to a
sane and reasonable state, you can "git stash pop" to move your local changes
from the stash back to the working tree.  If these changes conflict, you will
be left with conflicted files that need manual resolution, but that is all.
Think of the stash as a highly temporary branch (which is what it really is,
behind the scenes) to which your work has been saved for the time being.

Some people have even created a "git-smart-pull" utility that automatically
does a stash save/pop when necessary before a pull, in order to be consistent
in their workflow.  I don't have a link handy, but others might also use it
and can comment.

John

Re: git is screwed

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    If it were me, I would make sure to copy all changed files into a safe 
    place outside the git working tree to minimise any fallout from a failed 
    recovery attempt.

I don't know what all the changed files are.  I know which ones I changed
just recently.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: git is screwed

[Steinar Bang]

>>>>> Richard Stallman <rms@gnu.org>:

> Can someone tell me a full recipe for how to repair lisp/ChangeLog
> (perhaps, merge it by hand) and how to get the new version into
> the real repository?

I use magit (not (yet) on GNU Elpa, but available on marmalade (version
1.2.2) and Melpa (commit-triggered builds from magit git repo)), and
what I do, is: 

 1. 'M-x magit-status RET'
 2. This opens a buffer that looks like svn-status and pcl-cvs and it
    shows the results of the merge
     - The buffer will have three (maybe four) groups:
      - Untracked files
      - Unstaged changes
      - Staged changes
      - Unpushed commits (if you're working directly on a tracking branch)
     - Successfully merged files are shown under "Staged changes", and
       you can disregard them for now
     - Conflicted files are shown under "Unstaged changes" with a "C" in
       front of them
  3. I do 'g' in magit to ensure that any of the affected files I have
     in the buffers are reloaded from disk (this seems to happen
     automatically on emacs 24.4, but I still do the 'g')
  4. Then I enter the conflicted files and look for the conflict markers
     and see if I can make sense of them.  I usually force the file into
     fundamental-mode for this.  I try to manually fix the files and
     when I'm satisfied I move back to the magit buffer and position the
     cursor over the files and press 's" which moves the files from
     "Unstaged changes" to "Staged changes".
  5. As far as git is concerned the files are now reviewed and the merge
     can be completed, but I usually enter the file again and do "C-x v ="
     to view the diff and see if the diffs looks like I expected.
     I usually view the diffs of _all_ of the staged files before
     committing to see if they look sensible.  I also usually do a clean
     build, run unit tests and some smoke testing before committing
  6. In the magit buffer press 'c c' to commit the staged files.  The
     commit message comes up with git's default commit message. I
     usually add some comments about what I did with the conflicted
     files

The merge is now complete and resides in the newest commit locally.  To
push the changes upsteam from magit, do 'P P' (only available if you're
on a tracking branch).

Re: git is screwed

[Artur Malabarba]

2015-03-25 8:29 GMT+00:00 Steinar Bang <sb@dod.no>:
>>>>>> Richard Stallman <rms@gnu.org>:
>
>> Can someone tell me a full recipe for how to repair lisp/ChangeLog
>> (perhaps, merge it by hand) and how to get the new version into
>> the real repository?
>
> I use magit (not (yet) on GNU Elpa, but available on marmalade (version
> 1.2.2) and Melpa (commit-triggered builds from magit git repo)), and
> what I do, is:

Same here. Magit essentially took me from "I know git
commit/push/pull" to being (almost) a git expert. I'd strongly
recommend it to anyone, even those strugling with the concepts of git.

Re: git is screwed

[Stefan Monnier]

> I use magit (not (yet) on GNU Elpa,

BTW, it would be great to have Magit in GNU ELPA.  I can't remember the
outcome last time I contacted people about it, but if someone wants to
give it another try, that'd be great.


        Stefan

Re: git is screwed

[Steinar Bang]

>>>>> Stefan Monnier <monnier@iro.umontreal.ca>:

>> I use magit (not (yet) on GNU Elpa,
> BTW, it would be great to have Magit in GNU ELPA.  I can't remember the
> outcome last time I contacted people about it,

As far as I can remember both you and the Magit maintainers were
positive to getting magit into GNU ELPA.

Eli had concerns about the display code of magit, but he and one of the
magit developers entered in a discussion where they seemed to be in
agreement (my observation from following the discussion from the
sidelines...).

> but if someone wants to give it another try, that'd be great.

+1

Re: git is screwed

[Artur Malabarba]

>> I use magit (not (yet) on GNU Elpa,
>
> BTW, it would be great to have Magit in GNU ELPA.  I can't remember the
> outcome last time I contacted people about it, but if someone wants to
> give it another try, that'd be great.

I don't know what the outcome was, but the github graph says there are
42 people who've contributed at least 40 lines, so it might take some
effort.
https://github.com/magit/magit/graphs/contributors?from=2008-07-27&to=2015-03-21&type=a

Re: git is screwed

[Jonas Bernoulli]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I use magit (not (yet) on GNU Elpa,
>
> BTW, it would be great to have Magit in GNU ELPA.  I can't remember the
> outcome last time I contacted people about it, but if someone wants to
> give it another try, that'd be great.
>
>
>         Stefan

The outcome was that I said that I would first have to make a release.

And that I was not interested in being told that this is a misconception
of mine.  I understand that a package does not have to be "finished"
before being added to GNU Elpa, but ~4200 unreleased commits is kind of
a big deal.  99% of Magit's users are currently using a version which as
far as I am concerned has been obsolete for a year now (my mistake).

Fixing that is the primary, if not only, priority right now.  I going
to release 2.1.0 once the documentation is ready and that's still quite
a bit of work.  I don't have the time to discuss the possible inclusion
into GNU Elpa until the release has happened.  (And several people here
implying that those of us who have embraced the staging area suffer from
Stockholm syndrome certainly doesn't motivate me to rethink this decision).

  Jonas

Re: git is screwed

[Stefan Monnier]

> The outcome was that I said that I would first have to make a release.

In the mean time, other people could try and help collect the needed
copyright paperwork.


        Stefan

Re: git is screwed

[John Yates]

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

On Wed, Mar 25, 2015 at 7:23 PM, Jonas Bernoulli <jonas@bernoul.li> wrote:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> >> I use magit (not (yet) on GNU Elpa,
>
...
> The outcome was that I said that I would first have to make a release.
>

I am using Jonas' next branch of magit, easily available from github.
I install it via el-get using a variant recipe:

(:name magit
>        :description "It's Magit! An Emacs mode for Git."
>        :website     "https://github.com/magit/magit#readme"
>        :type        github
>        :pkgname     "magit/magit"
>        :branch      "next"
>        :depends     dash
>        :compile     "magit.*\.el\\'")


It is already eminently  usable.

/john

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

Re: git is screwed

[Stefan Monnier]

> It is already eminently  usable.

Emacs-25.0.50 is eminently usable in my experience, but it's still not
ready for release.

In any case, this is not really important: collecting all the copyright
assignment is what will take time.  By the time we have them all, 2.1
will most likely have been released (2.1 might even be old by then).


        Stefan

Re: git is screwed

[Steinar Bang]

>>>>> Jonas Bernoulli <jonas@bernoul.li>:

> (And several people here implying that those of us who have embraced
> the staging area suffer from Stockholm syndrome certainly doesn't
> motivate me to rethink this decision).

FWIW the way magit displays the staging area are one of the things that
makes it really useful to me.

The way magit displays a merge with conflicts, and makes me work with
the conflicts, makes it my favourite tool for resolving the conflicts.

I even use it for merges that have no conflicts.  It's the quickest way
to walk the staged files and examining the diffs, before I commit.

Re: git is screwed

[Alexis]

Steinar Bang <sb@dod.no> writes:

>>>>>> Jonas Bernoulli <jonas@bernoul.li>:
>
>> (And several people here implying that those of us who have 
>> embraced the staging area suffer from Stockholm syndrome 
>> certainly doesn't motivate me to rethink this decision).
>
> FWIW the way magit displays the staging area are one of the 
> things that makes it really useful to me.

+1.

Also, i've found that being able to stage regions /within hunks/ 
for staging, and thus being able to group together conceptually 
related changes easily, without needing to:

* go through multiple 'push stash -> delete unwanted -> pop stash' 
cycles, and/or

* deal with unneeded branch management bureaucracy,

helps me efficiently maintain a relatively clean commit history.

Thanks for your work on magit, i really appreciate it. :-)


Alexis.

Re: git is screwed

[Alexis]

Alexis <flexibeast@gmail.com> writes:

> * go through multiple 'push stash -> delete unwanted -> pop 
> stash'  cycles

Er, sorry, that should be more like:

    push stash -> apply stash -> delete unwanted -> commit
                \                                        /
                 -------------<------------------<-------
                
Using magit means i don't think much about such workflows 
nowadays. :-)


Alexis.

Re: git is screwed

[Artur Malabarba]

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

On Mar 26, 2015 8:00 AM, "Steinar Bang" <sb@dod.no> wrote:
>
> >>>>> Jonas Bernoulli <jonas@bernoul.li>:
>
> > (And several people here implying that those of us who have embraced
> > the staging area suffer from Stockholm syndrome certainly doesn't
> > motivate me to rethink this decision).
>
> FWIW the way magit displays the staging area are one of the things that
> makes it really useful to me.

Yes, in many ways, Magit helps git make sense.
The idea behind git's features is great, but most of them seemed pointless
to me until I viewed them under the light of Magit.

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

Re: git is screwed

[Rasmus]

Hi,

Jonas Bernoulli <jonas@bernoul.li> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:

> And that I was not interested in being told that this is a misconception
> of mine.

Out of curiosity, did anybody say that (I don't recall having seen it, and
I followed the last discussion on magit)?  If so it's obviously not OK.

> Fixing that is the primary, if not only, priority right now.  I going
> to release 2.1.0 once the documentation is ready and that's still quite
> a bit of work.

I'm excited to see this now, as I'm probably using the "obsolete" version.

> (And several people here implying that those of us who have embraced the
> staging area suffer from Stockholm syndrome certainly doesn't motivate
> me to rethink this decision).

I also haven't seen those posts either (I don't care much for "meta post
about git"), but it sounds unfortunate that somebody would use such harsh
words.

In any case, I often work on ISSUE X and thus become aware of BUGFIX Y.  I
will fix both and use magit to make different commits.  I have no idea how
to do that /without/ magit.  E.g. rebase -i and branch I find easier from
CLI, though I try to force myself to explore magit more.

—Rasmus

-- 
Lasciate ogni speranza o voi che entrate: siete nella mani di'machellaio

Re: git is screwed

[Ricardo Wurmus]

Rasmus writes:

> to do that /without/ magit.  E.g. rebase -i and branch I find easier from
> CLI, though I try to force myself to explore magit more.

Interactive rebasing is really convenient with magit-log, in my opinion.

I just select the commit from which I want to rebase and hit E.  In the
resulting buffer I can move around commits or mark them for further
actions.

Re: git is screwed

[Rasmus]

Ricardo Wurmus <rekado@elephly.net> writes:

> Rasmus writes:
>
>> to do that /without/ magit.  E.g. rebase -i and branch I find easier from
>> CLI, though I try to force myself to explore magit more.
>
> Interactive rebasing is really convenient with magit-log, in my opinion.
>
> I just select the commit from which I want to rebase and hit E.  In the
> resulting buffer I can move around commits or mark them for further
> actions.

Thanks for the tip.  It sounds cool, and I'll check it out.  I never
considered doing it from the the log view.  I think the manual mentions R
or something like that from the main view, but I checked it a while back.

—Rasmus

-- 
One thing that is clear: it's all down hill from here 

Re: git is screwed

[Jonas Bernoulli]

Rasmus <rasmus@gmx.us> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> Rasmus writes:
>>
>>> to do that /without/ magit.  E.g. rebase -i and branch I find easier from
>>> CLI, though I try to force myself to explore magit more.
>>
>> Interactive rebasing is really convenient with magit-log, in my opinion.
>>
>> I just select the commit from which I want to rebase and hit E.  In the
>> resulting buffer I can move around commits or mark them for further
>> actions.

This is not git's rebase but "rewriting" which is a Magit specific and
very bad implementation of the same basic idea.  I have removed it from
the next branch.  Don't use it.

> Thanks for the tip.  It sounds cool, and I'll check it out.  I never
> considered doing it from the the log view.  I think the manual mentions R
> or something like that from the main view, but I checked it a while back.

That's one area that has seen many improvements on the next
branch.  Some preliminary documentation can be found here:
https://github.com/magit/magit/wiki/History-Manipulation.

Re: git is screwed

[Harald Hanche-Olsen]

Maybe it is time to revisit this one, in light of what we have learned 
since.

Richard Stallman wrote:
> I committed some changes using C-x v v in vc-dir.
> Something went wrong with lisp/ChangeLog.
>
> It appears that my change log entries went into an old version of that
> file; I don't know why this happened, since I wrote them today after
> doing 'git pull'.

(“today” in this email is March 22)

Ah, but we have the output of git reflog now:

dca743f HEAD@{0}: commit: Recognize more format variation. Automatically 
reshow decrypted text.
1a80be1 HEAD@{1}: commit: Echo area shows when displaying a mime message.
414e79f HEAD@{2}: commit: Prefer IceCat to Firefox and Iceweasel.
f1cea3e HEAD@{3}: checkout: moving from TEST to master
f1cea3e HEAD@{4}: checkout: moving from master to TEST
f1cea3e HEAD@{5}: pull: Fast-forward
3517da7 Head@{6}: clone: from rms@git.sv.gnu.org:/srv/git/emacs.git

and there are no traces here of a successful pull after those three 
commits, which by the wat were all done in quick succession on March 22. 
The commit they are based on is f1cea3e, which is indeed about 8 weeks 
old. So it appears that your git pull failed, and you did edit an old 
lisp/ChangeLog.

> After this, I did 'git pull' again, and it said there was a merge
> conflict in lisp/ChangeLpg.  A lot of text appears to be missing from
> the file.  It said, "fix conflicts and then commit the result."
>
> I edited lisp/ChangeLog and tried to commit it with C-x v v.
> That gave me the error message
>
>    fatal: cannot do a partial commit during a merge.
>
> I am now stuck.  […]
>
> How can I get this unwedged?

We have also learned that “git ls-files -u” produces no output. That 
simplifies the available options somewhat, I think, since there are no 
unmerged files to deal with (they complicate the index quite a lot, 
since there may be several versions of these files there).

The only file different in the index and your working tree is 
lisp/ChangeLog. If you run “git diff”, you should see the difference 
between those two (in that order), and nothing else. If based on the 
output, you think the version in your working tree is more appropriate 
than the one in the index, you should go ahead and run “git add 
lisp/ChangeLog”. Otherwise, edit it further until satisfied, then run 
“git add lisp/ChangeLog”, at which point your working tree and index are 
in agreement (and “git diff” should produce no output).

The next thing you could try, is to run this command:

   git diff origin/master

This shows the difference between what is now in the working tree and 
what got fetched on your last I expect you will see all the changes you 
have made in your recent work, and nothing else. If so, go ahead and run 
“git commit“, but don't try to push yet. Your repository should now be 
in a sane state.

The only problem is that your latest additions – the ones you tried to 
commit with the initial C-x v v – will now be mixed in with the merge 
commit, which obscures the history. We might want to look into fixing 
that next.

– Harald

Re: git is screwed

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > and there are no traces here of a successful pull after those three 
  > commits, which by the wat were all done in quick succession on March 22. 
  > The commit they are based on is f1cea3e, which is indeed about 8 weeks 
  > old. So it appears that your git pull failed, and you did edit an old 
  > lisp/ChangeLog.

Maybe I did not recognize that it failed.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.