Re: stashing only unstaged changes?

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

 



My $0.02

On Tue, Jun 21, 2022 at 9:57 PM Tim Chase <git@xxxxxxxxxxxxxxxxx> 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.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux