Re: [Emacs-diffs] master b5b0e05: Call `smerge-start-session' even when dealing with a stash conflict

Re: [Emacs-diffs] master b5b0e05: Call `smerge-start-session' even when dealing with a stash conflict

[Stefan Monnier]

> +      (unless stashed
> +        ;; Stashes are tricky (bug#20292).
> +        (add-hook 'after-save-hook 'vc-git-resolve-when-done nil 'local))

I care a lot more about having Git know that the conflict is resolved,
than about the fine distinction between what was staged and what wasn't.

Actually, I think the above is too ad-hoc, testing `stashed' which is
only tangentially related to the problem.

Better would be for vc-git-resolve-when-done to check the status of the
file and only `git add' it if it doesn't have anything staged yet.  So,
it would still work as before in the case where there was nothing staged
before the "stash pop".

Or better yet, do the "mark as resolved" differently, which doesn't
involved touching the "staging area".  Not sure how to do that, but Git
aficionados should be able to find some clever hack for that, involving
less than 10 commands.


        Stefan

Re: [Emacs-diffs] master b5b0e05: Call `smerge-start-session' even when dealing with a stash conflict

[Dmitry Gutov]

On 04/20/2015 05:48 AM, Stefan Monnier wrote:

> I care a lot more about having Git know that the conflict is resolved,
> than about the fine distinction between what was staged and what wasn't.

Very well.

> Better would be for vc-git-resolve-when-done to check the status of the
> file and only `git add' it if it doesn't have anything staged yet.  So,
> it would still work as before in the case where there was nothing staged
> before the "stash pop".

Hmm, it seem I can't really detect whether the file had something staged 
(whether the conflict is due to that, or some new commits, 'git diff 
--cached', for instance, only says '* Unmerged path test2').

Maybe there's nothing to recover at that point anyway (someone feel free 
to correct me here).

> Or better yet, do the "mark as resolved" differently, which doesn't
> involved touching the "staging area".  Not sure how to do that, but Git
> aficionados should be able to find some clever hack for that, involving
> less than 10 commands.

Guess I'm not enough of an aficionado, then. After plenty of searching 
and reading the man pages, 'git add' followed by 'git reset' is the best 
I have.

Re: [Emacs-diffs] master b5b0e05: Call `smerge-start-session' even when dealing with a stash conflict

[Dmitry Gutov]

On 04/20/2015 04:14 PM, Dmitry Gutov wrote:

> Hmm, it seem I can't really detect whether the file had something staged

IOW, the best indicator we have of whether to reset or not, AFAICT, is 
the presence of .git/MERGE_HEAD.

Re: [Emacs-diffs] master b5b0e05: Call `smerge-start-session' even when dealing with a stash conflict

[Eli Zaretskii]

> Date: Mon, 20 Apr 2015 16:14:05 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> > Or better yet, do the "mark as resolved" differently, which doesn't
> > involved touching the "staging area".  Not sure how to do that, but Git
> > aficionados should be able to find some clever hack for that, involving
> > less than 10 commands.
> 
> Guess I'm not enough of an aficionado, then. After plenty of searching 
> and reading the man pages, 'git add' followed by 'git reset' is the best 
> I have.

AFAIU, "git add" is not needed, "git reset HEAD FILE" is enough.

Re: [Emacs-diffs] master b5b0e05: Call `smerge-start-session' even when dealing with a stash conflict

[Stefan Monnier]

>> Better would be for vc-git-resolve-when-done to check the status of the
>> file and only `git add' it if it doesn't have anything staged yet.  So,
>> it would still work as before in the case where there was nothing staged
>> before the "stash pop".
> Hmm, it seem I can't really detect whether the file had something staged
> (whether the conflict is due to that, or some new commits, 'git
> diff --cached', for instance, only says '* Unmerged path test2').

"git status --porcelain <file>" gives me:

  "M  <file>"

for a file with staged changes

  " M <file>"

for a modified file with no staged changes, and

  "MM <file>"

for a modified file with both staged and unstaged changes.  So I think
that looking for "\\`M" in the output of "git status --porcelain"
should work.

Of course, what I'm proposing would still add the file to the staging
area, even if the user did not originally intend to do so, but at least
there's no serious loss of information (the only loss of information is
"which files(s)'s changes were already staged and which weren't").

> Guess I'm not enough of an aficionado, then.  After plenty of searching and
> reading the man pages, 'git add' followed by 'git reset' is the best I have.

Well, if you're not afraid of getting gross, you could do something
along the lines of:

   unstaged=$(git diff -- <file>)
   git add <file>
   echo "$unstaged" | patch -R -p1
   git add <file>
   echo "$unstaged" | patch -p1


-- Stefan

Re: [Emacs-diffs] master b5b0e05: Call `smerge-start-session' even when dealing with a stash conflict

[Dmitry Gutov]

On 04/20/2015 06:25 PM, Stefan Monnier wrote:

> So I think
> that looking for "\\`M" in the output of "git status --porcelain"
> should work.

I see

$ git status --porcelain
UU test2

in both cases of stash-related conflict.

Haven't time to test what happens during the usual merge operation.

> Well, if you're not afraid of getting gross, you could do something
> along the lines of:
>
>     unstaged=$(git diff -- <file>)
>     git add <file>
>     echo "$unstaged" | patch -R -p1
>     git add <file>
>     echo "$unstaged" | patch -p1

Ehh, I considered something like this, but it looks brittle. A failure 
in one of the middle steps means the user loses their edits.

Re: [Emacs-diffs] master b5b0e05: Call `smerge-start-session' even when dealing with a stash conflict

[Stefan Monnier]

> Ehh, I considered something like this, but it looks brittle.  A failure in
> one of the middle steps means the user loses their edits.

Yes, it's hideous.  We should report it as a Git bug.


        Stefan

Re: [Emacs-diffs] master b5b0e05: Call `smerge-start-session' even when dealing with a stash conflict

[Dmitry Gutov]

On 04/20/2015 10:39 PM, Stefan Monnier wrote:

> Yes, it's hideous.  We should report it as a Git bug.

http://thread.gmane.org/gmane.comp.version-control.git/267500

Re: [Emacs-diffs] master b5b0e05: Call `smerge-start-session' even when dealing with a stash conflict

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Sun, 19 Apr 2015 22:48:24 -0400
> Cc: Dmitry Gutov <dgutov@yandex.ru>
> 
> Actually, I think the above is too ad-hoc, testing `stashed' which is
> only tangentially related to the problem.

The bug was specifically about incorrect staging of stashed changes,
which were supposed to be left unstaged and uncommitted after
resolving the conflict.  So I don't see how this is tangential to the
problem; AFAIU it _is_ the problem.

> Better would be for vc-git-resolve-when-done to check the status of the
> file and only `git add' it if it doesn't have anything staged yet.

Why should what we do with some file depend on whether there are other
changes staged?  (Or maybe I don't understand what "it" means in this
case.)

> Or better yet, do the "mark as resolved" differently, which doesn't
> involved touching the "staging area".  Not sure how to do that, but Git
> aficionados should be able to find some clever hack for that, involving
> less than 10 commands.

The way I know of is "git reset HEAD FILE".  But is that safe in the
case in point?