emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#60126: closed (30.0.50; vc-git-checkin: Offer to unstage conflicting


From: GNU bug Tracking System
Subject: bug#60126: closed (30.0.50; vc-git-checkin: Offer to unstage conflicting changes)
Date: Sat, 24 Dec 2022 02:03:02 +0000

Your message dated Fri, 23 Dec 2022 19:02:14 -0700
with message-id <8735958spl.fsf@melete.silentflame.com>
and subject line Re: bug#60126: 30.0.50; vc-git-checkin: Offer to unstage 
conflicting changes
has caused the debbugs.gnu.org bug report #60126,
regarding 30.0.50; vc-git-checkin: Offer to unstage conflicting changes
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
60126: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=60126
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: 30.0.50; vc-git-checkin: Offer to unstage conflicting changes Date: Fri, 16 Dec 2022 18:32:54 +0000
X-debbugs-cc: juri@linkov.net, dgutov@yandex.ru

I seem often to end up with a nonempty index when trying to commit patches
using C-x v v from diff-mode, so I came up with this patch.

-- 
Sean Whitton

Attachment: 0001-vc-git-checkin-Offer-to-unstage-conflicting-changes.patch
Description: Text Data


--- End Message ---
--- Begin Message --- Subject: Re: bug#60126: 30.0.50; vc-git-checkin: Offer to unstage conflicting changes Date: Fri, 23 Dec 2022 19:02:14 -0700 User-agent: Gnus/5.13 (Gnus v5.13)
Hello,

On Sat 24 Dec 2022 at 01:18AM +02, Dmitry Gutov wrote:

> On 23/12/2022 05:59, Sean Whitton wrote:
>> It works, except that sometimes the let-binding of process-environment
>> fails, such that the commands affect the normal index rather than the
>> temporary index.  Can you see what I'm doing wrong there?
>
> Could you describe be "sometimes" occurrences? Does that happen through
> repeating a similar action several times? Or slightly different actions?
>
> The process-environment setup seems fine. We did corrupt it in 1-2 places in
> the past using 'setenv', but I don't see anything like that in the current
> codebase. And the effect would probably be different anyway.

Thank you for looking.  Slightly embarassingly, I can't reproduce the
problem today.  So I've gone ahead and pushed.

I am pretty happy with this approach, in the end.  Compared with other
possible uses of 'git stash', it's quite clean:

- it doesn't touch the worktree copies of the files not involved in the
  commit

- it stashes a single diff, rather than two diffs (one for the worktree
  and one for the index), which is less for the user to deal with if
  manual recovery becomes required.

Thanks again for the helpful discussion on this one.

-- 
Sean Whitton


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]