git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Erik Cervin Edin <erik@cervined.in>
To: Tim Chase <git@tim.thechases.com>
Cc: git@vger.kernel.org
Subject: Re: stashing only unstaged changes?
Date: Fri, 24 Jun 2022 13:23:34 +0200	[thread overview]
Message-ID: <CA+JQ7M9jBSB8tdpz85imER4SF1yhn3jes8ThnzkA_O9+mus1Ng@mail.gmail.com> (raw)
In-Reply-To: <20220621142618.239b02cd@bigbox.attlocal.net>

My $0.02

On Tue, Jun 21, 2022 at 9:57 PM Tim Chase <git@tim.thechases.com> wrote:
>
> I recently had composed a commit with some `git add -p` leaving some
> portions unstaged. I wanted to stash the unstaged changes to make
> sure that the staged code ran as expected, so I did  a `git stash`
> only to find that it unstaged my staged changes and stashed
> *everything*.

What you wanted to do was
  git stash --keep-index
which creates a stash with the staged and unstaged changes but leaves
the staged ones in the working tree.

If you forget to do this, what you do is try
  git stash pop --index
and then
  git stash --keep-index

> Using `git stash --saved` does the opposite of what I want (stashing
> the index, not the difference between the index and the working-copy)

I'm unaware of a --saved option

My understanding (which may be incorrect) is that a shash is always of
the staged/unstaged changes and there's no way to stash only one or
the other in a single stash operation.

> So I carefully re-`git add -p`'ed everything and tried `git stash
> --keep-index` which sounded promising (my index remained the same),
> but popping my stash ended up causing conflicts because it had
> stashed the diff of HEAD..working-copy, not INDEX..working-copy.  A
> `git stash show -p` confirmed that the stash included things that I
> had already staged.

Such conflicts are usually trivially be resolved by taking "theirs"
I have a helper script that does this and it's basically
  git ls-files --unmerged -z |\
    xargs -0 sed -i -e '/^<\{7\}/,/^=\{7\}/d' --e '/^>\{7\}/d' &&
    git ls-files --unmerged -z | xargs -0 git add --
though, unfortunately, it also stages the content as a part of marking
resolution.

> So I carefully re-`git add -p`ed everything yet again, but then got
> stuck trying to convince `stash` to save a snapshot of only the diff
> in my working directory.

A stash is always both staged and unstaged changes of the files.

To stash only staged you may do
  git stash --keep-index
  git stash
The first stash will include staged/unstaged and the second only staged

To create a stash of only unstaged
  git commit -m tmp # create temporary commit w staged
  git stash # stash unstaged
  git reset HEAD~ &&  git stash # stash the previous staged as
unstaged (optionally git add  in the middle)
  git stash apply/pop stash@{1} # get the "unstaged" stash
As you noted such a stash is still based on a tree that may have
contained staged changes (ORIG_HEAD).
Ie. if you staged line 1 but not 2-3 the "unstaged" stash will also
contain line 1
This is doesn't happen if the staged/unstaged contain different files

> To work around it, I did a `git diff >
> temp.patch` to obtain the stuff I'd wanted to stash, a `git reset
> --staged` to clear out those changes, ran my code to verify
> (eventually committing it), and then applied the `temp.patch` back on
> top of my changes. It worked, but felt convoluted.

That's basically what you have to do if you only want certain changes.
(and also what --patch does under the hood)

> I did see the `git stash -p` option, to manually choose the inverse
> bits, but for what I was doing, it was more sensible to `git add -p`
> and try to stash the rest.

git stash --patch is MUCH slower than git add -p, so I personally never use it.
In my workflow I find it better to either
  git add -p
and then
  git stash --keep-index
or creating regular temporary commits, and fiddling with those,
perhaps using rebase and friends.

> So is there some option I've missed to tell `git stash` to stash only
> the delta between the uncommitted-index and the working-copy?

No, there is none.

In my experience, using regular
add/commit/reset/branch/checkout/rebase is superior to using the stash
for separating changes into discrete commits.

  parent reply	other threads:[~2022-06-24 11:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-21 19:26 stashing only unstaged changes? Tim Chase
2022-06-24  8:16 ` Reto
2022-06-24 20:53   ` Tim Chase
2022-06-24  9:55 ` Konstantin Khomoutov
2022-06-24 11:23 ` Erik Cervin Edin [this message]
2022-06-24 20:38   ` Tim Chase
2022-06-24 13:09 ` Ævar Arnfjörð Bjarmason
2022-06-24 13:49   ` Erik Cervin Edin
2022-06-24 15:32     ` Ævar Arnfjörð Bjarmason
2022-06-24 19:47       ` Junio C Hamano

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: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+JQ7M9jBSB8tdpz85imER4SF1yhn3jes8ThnzkA_O9+mus1Ng@mail.gmail.com \
    --to=erik@cervined.in \
    --cc=git@tim.thechases.com \
    --cc=git@vger.kernel.org \
    /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://80x24.org/mirrors/git.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).