Resuming M-x gitmerge

Resuming M-x gitmerge

[Noam Postavsky]

When M-x gitmerge hits a conflict, it shows a window with the message:

    Resolve the conflicts manually, then run gitmerge again.
    Note:
      - You don't have to add resolved files or commit the merge yourself (but you can).
      - You can safely close this Emacs session and do this in a new one.
      - When running gitmerge again, remember that you must do that from within the Emacs repo.

The first note is either wrong, or I'm misunderstanding it.  If I don't
'git add' the resolved files and commit the merge, then trying to run
M-x gitmerge again fails with (user-error "Repository is not clean").

So what is the intended workflow here?

Re: Resuming M-x gitmerge

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Date: Sun, 10 Jun 2018 19:54:58 -0400
> Cc: Glenn Morris <rgm@gnu.org>
> 
> When M-x gitmerge hits a conflict, it shows a window with the message:
> 
>     Resolve the conflicts manually, then run gitmerge again.
>     Note:
>       - You don't have to add resolved files or commit the merge yourself (but you can).
>       - You can safely close this Emacs session and do this in a new one.
>       - When running gitmerge again, remember that you must do that from within the Emacs repo.
> 
> The first note is either wrong, or I'm misunderstanding it.  If I don't
> 'git add' the resolved files and commit the merge, then trying to run
> M-x gitmerge again fails with (user-error "Repository is not clean").

I was under the impression that resolving conflicts and saving the
modified files automatically runs "git add" on the files.

Re: Resuming M-x gitmerge

[João Távora]

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

On Mon, Jun 11, 2018, 03:38 Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Noam Postavsky <npostavs@gmail.com>
> > Date: Sun, 10 Jun 2018 19:54:58 -0400
> > Cc: Glenn Morris <rgm@gnu.org>
> >
> > When M-x gitmerge hits a conflict, it shows a window with the message:
> >
> >     Resolve the conflicts manually, then run gitmerge again.
> >     Note:
> >       - You don't have to add resolved files or commit the merge
> yourself (but you can).
> >       - You can safely close this Emacs session and do this in a new one.
> >       - When running gitmerge again, remember that you must do that from
> within the Emacs repo.
> >
> > The first note is either wrong, or I'm misunderstanding it.  If I don't
> > 'git add' the resolved files and commit the merge, then trying to run
> > M-x gitmerge again fails with (user-error "Repository is not clean").
>
> I was under the impression that resolving conflicts and saving the
> modified files automatically runs "git add" on the files.
>

It does. Sometimes, but not always. I've never figured out the conditions
that lead to each situation. I'm not using M-x gitmerge btw, just regular
smerge.

João

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

Re: Resuming M-x gitmerge

[Noam Postavsky]

On 11 June 2018 at 02:54, João Távora <joaotavora@gmail.com> wrote:
> On Mon, Jun 11, 2018, 03:38 Eli Zaretskii <eliz@gnu.org> wrote:
>>
>> > From: Noam Postavsky <npostavs@gmail.com>
>> > Date: Sun, 10 Jun 2018 19:54:58 -0400
>> > Cc: Glenn Morris <rgm@gnu.org>
>> >
>> > When M-x gitmerge hits a conflict, it shows a window with the message:
>> >
>> >     Resolve the conflicts manually, then run gitmerge again.
>> >     Note:
>> >       - You don't have to add resolved files or commit the merge
>> > yourself (but you can).

>> > The first note is either wrong, or I'm misunderstanding it.  If I don't
>> > 'git add' the resolved files and commit the merge, then trying to run
>> > M-x gitmerge again fails with (user-error "Repository is not clean").
>>
>> I was under the impression that resolving conflicts and saving the
>> modified files automatically runs "git add" on the files.
>
>
> It does. Sometimes, but not always. I've never figured out the conditions
> that lead to each situation. I'm not using M-x gitmerge btw, just regular
> smerge.

I think it's a new (default?) behaviour change in smerge-mode as of
Emacs 25. Anyway, it doesn't matter for M-x gitmerge, because
gitmerge-repo-clean checks for both staged and unstaged changes.
Therefore it seems that you *must* "add resolved files and commit the
merge yourself" in order to proceed.

Re: Resuming M-x gitmerge

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Date: Mon, 11 Jun 2018 08:40:21 -0400
> Cc: Eli Zaretskii <eliz@gnu.org>, Glenn Morris <rgm@gnu.org>, Emacs developers <emacs-devel@gnu.org>
> 
> >> I was under the impression that resolving conflicts and saving the
> >> modified files automatically runs "git add" on the files.
> >
> >
> > It does. Sometimes, but not always. I've never figured out the conditions
> > that lead to each situation. I'm not using M-x gitmerge btw, just regular
> > smerge.
> 
> I think it's a new (default?) behaviour change in smerge-mode as of
> Emacs 25. Anyway, it doesn't matter for M-x gitmerge, because
> gitmerge-repo-clean checks for both staged and unstaged changes.
> Therefore it seems that you *must* "add resolved files and commit the
> merge yourself" in order to proceed.

That's an annoyance.  Why was the default changed, and why cannot
gitmerge override the default so manually running "git add" is not
required?

Re: Resuming M-x gitmerge

[Stefan Monnier]

>> I think it's a new (default?) behaviour change in smerge-mode as of
>> Emacs 25. Anyway, it doesn't matter for M-x gitmerge, because
>> gitmerge-repo-clean checks for both staged and unstaged changes.
>> Therefore it seems that you *must* "add resolved files and commit the
>> merge yourself" in order to proceed.
> That's an annoyance.  Why was the default changed, and why cannot

IIUC the change referred to is that before Emacs-25, VC didn't
automatically "git add" when finishing an smerge session.
IOW the annoyance affects Emacs<25 rather than Emacs≥25.


        Stefan

Re: Resuming M-x gitmerge

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 11 Jun 2018 11:46:53 -0400
> 
> >> I think it's a new (default?) behaviour change in smerge-mode as of
> >> Emacs 25. Anyway, it doesn't matter for M-x gitmerge, because
> >> gitmerge-repo-clean checks for both staged and unstaged changes.
> >> Therefore it seems that you *must* "add resolved files and commit the
> >> merge yourself" in order to proceed.
> > That's an annoyance.  Why was the default changed, and why cannot
> 
> IIUC the change referred to is that before Emacs-25, VC didn't
> automatically "git add" when finishing an smerge session.
> IOW the annoyance affects Emacs<25 rather than Emacs≥25.

OK, but then why doesn't it work for Noam with the current versions of
Emacs?

Re: Resuming M-x gitmerge

[Noam Postavsky]

On 11 June 2018 at 12:00, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Date: Mon, 11 Jun 2018 11:46:53 -0400
>>
>> >> I think it's a new (default?) behaviour change in smerge-mode as of
>> >> Emacs 25. Anyway, it doesn't matter for M-x gitmerge, because
>> >> gitmerge-repo-clean checks for both staged and unstaged changes.
>> >> Therefore it seems that you *must* "add resolved files and commit the
>> >> merge yourself" in order to proceed.
>> > That's an annoyance.  Why was the default changed, and why cannot
>>
>> IIUC the change referred to is that before Emacs-25, VC didn't
>> automatically "git add" when finishing an smerge session.
>> IOW the annoyance affects Emacs<25 rather than Emacs≥25.
>
> OK, but then why doesn't it work for Noam with the current versions of
> Emacs?

Miscommunication; when I said that I had "add resolved files" I
considered using smerge to automatically to call 'git add'
automatically as adding the resolved files (i.e., that gitmerge.el
doesn't do it).
Anyway, the real question is about the committing the merge it seems.

Re: Resuming M-x gitmerge

[Glenn Morris]

Noam Postavsky wrote:

> When M-x gitmerge hits a conflict, it shows a window with the message:
>
>     Resolve the conflicts manually, then run gitmerge again.
>     Note:
>       - You don't have to add resolved files or commit the merge yourself (but you can).
[...]
> The first note is either wrong, or I'm misunderstanding it.  If I don't
> 'git add' the resolved files and commit the merge, then trying to run
> M-x gitmerge again fails with (user-error "Repository is not clean").

Maybe it's just badly worded? You have to resolve the conflict someway.
This is either by editing the conflicted file and using "git add" to
mark it as resolved, or by reset+checkout (or whatever the voodooo is)
to discard the changes altogether. I don't remember needing to manually
"commit" myself. Normally I think I do:

M-x gitmerge
fix conflict
git add <file> to mark conflict resolved
  (unless eg smerge has automatically done that)
M-x gitmerge

So maybe it should just say "You don't have to commit the merge yourself..."

Re: Resuming M-x gitmerge

[Noam Postavsky]

On 11 June 2018 at 11:50, Glenn Morris <rgm@gnu.org> wrote:
> Noam Postavsky wrote:
>
>> When M-x gitmerge hits a conflict, it shows a window with the message:
>>
>>     Resolve the conflicts manually, then run gitmerge again.
>>     Note:
>>       - You don't have to add resolved files or commit the merge yourself (but you can).
> [...]
>> The first note is either wrong, or I'm misunderstanding it.  If I don't
>> 'git add' the resolved files and commit the merge, then trying to run
>> M-x gitmerge again fails with (user-error "Repository is not clean").
>
> Maybe it's just badly worded? You have to resolve the conflict someway.
> This is either by editing the conflicted file and using "git add" to
> mark it as resolved, or by reset+checkout (or whatever the voodooo is)
> to discard the changes altogether. I don't remember needing to manually
> "commit" myself. Normally I think I do:
>
> M-x gitmerge
> fix conflict
> git add <file> to mark conflict resolved
>   (unless eg smerge has automatically done that)
> M-x gitmerge

Hmm, this didn't work for me, I needed to commit the merge.
And given the current implementation of gitmerge-repo-clean I can't
see how it could work any other way.

> So maybe it should just say "You don't have to commit the merge yourself..."

Yes (assuming it's supposed to work without committing the merge) I
would find this wording clearer.

Re: Resuming M-x gitmerge

[Glenn Morris]

Noam Postavsky wrote:

> Hmm, this didn't work for me, I needed to commit the merge.
> And given the current implementation of gitmerge-repo-clean I can't
> see how it could work any other way.

I did:
git reset --hard f4e9ceacda
emacs -Q -l admin/gitmerge.el
M-x gitmerge
...
M-x kill-emacs
git add src/ftfont.c

git status now reports:

# All conflicts fixed but you are still merging.
#   (use "git commit" to conclude merge)
#
# Changes to be committed:
#
#	modified:   ChangeLog.3
#	modified:   etc/NEWS
#	modified:   lisp/comint.el
#	modified:   lisp/simple.el
#	modified:   src/ftfont.c


At this point I can now run:
emacs -Q -nw -l admin/gitmerge.el
M-x gitmerge

and it prompts "resume merge?" and is happy to continue on "y".

This is how I've been doing it.

PS maybe totally unrelated, but I made this note a while ago, and never
investigated:

"is gitmerge discarding commits when there are more than one and then a
conflict? example: 20180302
emacs-26  0213c8b
master 82f12b2"

I'm no longer even sure what I meant, so feel free to ignore.

Re: Resuming M-x gitmerge

[David Engster]

Noam Postavsky writes:
> On 11 June 2018 at 11:50, Glenn Morris <rgm@gnu.org> wrote:
>> Noam Postavsky wrote:
>>
>>> When M-x gitmerge hits a conflict, it shows a window with the message:
>
>>>
>>>     Resolve the conflicts manually, then run gitmerge again.
>>>     Note:
>>>       - You don't have to add resolved files or commit the merge yourself (but you can).
>> [...]
>>> The first note is either wrong, or I'm misunderstanding it.  If I don't
>>> 'git add' the resolved files and commit the merge, then trying to run
>>> M-x gitmerge again fails with (user-error "Repository is not clean").
>>
>> Maybe it's just badly worded? You have to resolve the conflict someway.
>> This is either by editing the conflicted file and using "git add" to
>> mark it as resolved, or by reset+checkout (or whatever the voodooo is)
>> to discard the changes altogether. I don't remember needing to manually
>> "commit" myself. Normally I think I do:
>>
>> M-x gitmerge
>> fix conflict
>> git add <file> to mark conflict resolved
>>   (unless eg smerge has automatically done that)
>> M-x gitmerge
>
> Hmm, this didn't work for me, I needed to commit the merge.
> And given the current implementation of gitmerge-repo-clean I can't
> see how it could work any other way.

Look in `gitmerge-maybe-resume': It checks if there's an ongoing merge
(by checking for .git/MERGE_HEAD) and also a status file from a previous
gitmerge run. If that is both the case and the user accepts the resume,
it will jump to `gitmerge-resolve-unmerged', which should add all
non-conflicted files and commit the merge.

-David

Re: Resuming M-x gitmerge

[Noam Postavsky]

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

>> And given the current implementation of gitmerge-repo-clean I can't
>> see how it could work any other way.

Turns out I got a bit confused reading the boolean expression in
gitmerge-repo-clean.

On 11 June 2018 at 15:31, David Engster <deng@randomsample.de> wrote:

> Look in `gitmerge-maybe-resume': It checks if there's an ongoing merge
> (by checking for .git/MERGE_HEAD) and also a status file from a previous
> gitmerge run. If that is both the case and the user accepts the resume,
> it will jump to `gitmerge-resolve-unmerged', which should add all
> non-conflicted files and commit the merge.

Oh, I see what it is. The reason it doesn't work for me is that I use
git-worktree, so the .git/MERGE_HEAD test gives the wrong answer. And
now I see that gitmerge-resolve does actually do 'git add' if needed,
so the current message is actually perfectly fine. The attached lets
it work for me, I think that should cover everything.

[-- Attachment #2: 0001-Don-t-assume-.git-is-a-directory-in-gitmerge.el.patch --]
[-- Type: text/x-diff, Size: 1282 bytes --]

From a3d2a66d97a6488f99233ead357eab0d7055c3c8 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs@gmail.com>
Date: Mon, 11 Jun 2018 20:41:07 -0400
Subject: [PATCH] Don't assume .git is a directory in gitmerge.el

* admin/gitmerge.el (gitmerge-maybe-resume): Use 'git rev-parse
--git-dir' to find the git directory rather than assuming it is
.git/ (that assumption fails for separated worktrees).
---
 admin/gitmerge.el | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/admin/gitmerge.el b/admin/gitmerge.el
index e676e8fa02..8a8444aa40 100644
--- a/admin/gitmerge.el
+++ b/admin/gitmerge.el
@@ -483,8 +483,12 @@ gitmerge-commit
 (defun gitmerge-maybe-resume ()
   "Check if we have to resume a merge.
 If so, add no longer conflicted files and commit."
-  (let ((mergehead (file-exists-p
-		    (expand-file-name ".git/MERGE_HEAD" default-directory)))
+  (let ((mergehead ;git_common_dir=
+         (file-exists-p
+	  (expand-file-name
+           "MERGE_HEAD"
+           (car (process-lines
+                 "git" "rev-parse" "--no-flags" "--git-dir")))))
 	(statusexist (file-exists-p gitmerge-status-file)))
     (when (and mergehead (not statusexist))
       (user-error "Unfinished merge, but no record of a previous gitmerge run"))
-- 
2.11.0

Re: Resuming M-x gitmerge

[Noam Postavsky]

On 11 June 2018 at 20:48, Noam Postavsky <npostavs@gmail.com> wrote:

> Oh, I see what it is. The reason it doesn't work for me is that I use
> git-worktree, so the .git/MERGE_HEAD test gives the wrong answer. And
> now I see that gitmerge-resolve does actually do 'git add' if needed,
> so the current message is actually perfectly fine. The attached lets
> it work for me, I think that should cover everything.

Pushed to master.

[1: 5498acb5a2]: 2018-06-18 20:02:04 -0400
  Stop assuming .git is a directory in gitmerge.el
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=5498acb5a2b4a19060d17c0e2ce0aec36ee684f9