GNU bug report logs - #60126
30.0.50; vc-git-checkin: Offer to unstage conflicting changes

Previous Next

Full log

Message #35 received at 60126 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 60126 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#60126: 30.0.50; vc-git-checkin: Offer to unstage
 conflicting changes
Date: Tue, 20 Dec 2022 10:04:34 -0700

Hello,

On Tue 20 Dec 2022 at 05:13PM +02, Dmitry Gutov wrote:

> On 20/12/2022 08:43, Sean Whitton wrote:
>> So, I'm now thinking:
>> - automatically stash index+worktree for any files with changes staged
>>    that are*not*  modified by the patch to be committed
>
> I think it's possible to just skip those when checking the index area. And
> then, when committing, specify individual files to commit from the index.

Ah, so it is!

> E.g. this way:
>
> diff --git a/lisp/vc/vc-git.el b/lisp/vc/vc-git.el
> index b5959d535c0..dee102d8586 100644
> --- a/lisp/vc/vc-git.el
> +++ b/lisp/vc/vc-git.el
> @@ -1052,7 +1052,7 @@ vc-git-checkin
>                 (lambda (value) (when (equal value "yes") (list argument)))))
>        ;; When operating on the whole tree, better pass "-a" than ".", since
>          "."
>        ;; fails when we're committing a merge.
> -      (apply #'vc-git-command nil 0 (if (and only (not vc-git-patch-string))
>       files)
> +      (apply #'vc-git-command nil 0 (if only files)
>               (nconc (if msg-file (list "commit" "-F"
>                                         (file-local-name msg-file))
>                        (list "commit" "-m"))
>
> (I'm not sure if the list of files is passed to this function correctly when
> committing a patch; if not, fixing that would also be needed.)

It's not usually passed, but it could be.  So I think I need to clear
out files and populate it again during the loop through
vc-git-patch-string.  We'll want this always to happen, so in the commit
command we'll want (and (or only vc-git-patch-string) files).

>> - offer to unstage any files with changes staged that*are*  modified by
>>    the patch to be committed.
>
> Or we could just abort, like we do now. Up to you (do you encounter this
> particular situation often?).

I feel like I do, yes, though I'm not completely sure which of the two
situations I keep finding myself in.  It does no harm to have the
feature, at least.

Thank you for the input.

-- 
Sean Whitton

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.