From: Sean Whitton <spwhitton@spwhitton.name>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: 60126@debbugs.gnu.org, juri@linkov.net
Subject: bug#60126: 30.0.50; vc-git-checkin: Offer to unstage conflicting changes
Date: Tue, 20 Dec 2022 16:10:00 -0700 [thread overview]
Message-ID: <87zgbh1xkn.fsf@melete.silentflame.com> (raw)
In-Reply-To: <87h6xqgg65.fsf@melete.silentflame.com> (Sean Whitton's message of "Tue, 20 Dec 2022 10:04:34 -0700")
Hello,
On Tue 20 Dec 2022 at 10:04AM -07, Sean Whitton wrote:
> 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!
It turns out this doesn't work: if you specify individual files to
commit from the index, then git also includes any changes to those files
in the worktree too, and you can't ask it not to, because --only is
implied whenever files are supplied on the command line.
In other words, when vc-git-patch-string is non-nil, we mustn't pass a
list of files to git. So if there are files not involved in the commit
with staged changes, we need to stash those.
I tried implementing that, which is not hard, but then we pop that
stash, the staged changes aren't restored to the index. The result is
that if the user has a mixture of staged and unstaged changes to a file
which is not part of the commit, then afterwards the unstaged changes
will have been unstaged, mixed in with the staged changes again. In
some circumstances this could constitute a loss of work.
There are a few ways to overcome this. We can use the --staged option,
but that's only available in very recent versions of git. We could
perform a complex double-stash:
- git stash push -k -- foo
- git reset -- foo
- git stash push -k -- foo
- [commit]
- git stash pop
- git add -- foo
- git stash pop
Or we could do something like what Magit does to stash only the index.
Any thoughts on what would be best?
In the meantime, I've pushed a version of my previous patch, as I think
it makes sense to implement the stashing, if we do, as a second change.
--
Sean Whitton
next prev parent reply other threads:[~2022-12-20 23:10 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-16 18:32 bug#60126: 30.0.50; vc-git-checkin: Offer to unstage conflicting changes Sean Whitton
2022-12-17 17:06 ` Juri Linkov
2022-12-18 0:20 ` Sean Whitton
2022-12-18 1:08 ` Dmitry Gutov
2022-12-19 22:30 ` Sean Whitton
2022-12-20 0:53 ` Dmitry Gutov
2022-12-20 6:43 ` Sean Whitton
2022-12-20 13:47 ` Dmitry Gutov
2022-12-20 16:47 ` Sean Whitton
2022-12-20 15:13 ` Dmitry Gutov
2022-12-20 17:04 ` Sean Whitton
2022-12-20 23:10 ` Sean Whitton [this message]
2022-12-20 23:41 ` Sean Whitton
2022-12-20 23:45 ` Dmitry Gutov
2022-12-23 0:12 ` Sean Whitton
2022-12-23 3:59 ` Sean Whitton
2022-12-23 8:16 ` Eli Zaretskii
2022-12-24 2:03 ` Sean Whitton
2022-12-23 23:18 ` Dmitry Gutov
2022-12-24 2:02 ` Sean Whitton
2022-12-24 14:50 ` Dmitry Gutov
2022-12-24 18:22 ` Sean Whitton
2022-12-24 19:26 ` Dmitry Gutov
2022-12-24 20:10 ` Sean Whitton
2022-12-23 22:55 ` Dmitry Gutov
2022-12-20 17:13 ` Juri Linkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zgbh1xkn.fsf@melete.silentflame.com \
--to=spwhitton@spwhitton.name \
--cc=60126@debbugs.gnu.org \
--cc=dgutov@yandex.ru \
--cc=juri@linkov.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).