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

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

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


From: Dmitry Gutov
Subject: bug#60126: 30.0.50; vc-git-checkin: Offer to unstage conflicting changes
Date: Wed, 21 Dec 2022 01:45:37 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

On 21/12/2022 01:10, Sean Whitton wrote:
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.

IIUC the --staged option is indeed limited to the very new Git, but that option is used when creating a stash (when we want to stash the staging area only).

When restoring a stash, to reinstate the stashed index, you would use the option --index. It's older than --staged (e.g. it's available in Git 2.22.0, and that's as far back as the docs at git-scm.com/docs go). Not sure if it's in Debian Stable or not.

Regarding the alternatives -- double stashing, or the Magit way, it's hard to form a strong opinion before examining them in detail (I trust you can make a good choice).

For completeness, though, here's a way to implement 'git push --staged' with Git plumbing manually: https://stackoverflow.com/a/72582276/615245

And as for a 'git pop --index' substitute, if the stash contains only the index area stuff, it might be as easy as

  git diff stash@{0}^..stash@{0} > patch.diff
  git apply --cached patch.diff
  git stash drop






reply via email to

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