Re: stashing only unstaged changes?

From: Tim Chase <git@tim.thechases.com>
Date: Jun 24, 2022, 20:38 UTC
Message-ID: <20220624153804.44089117@bigbox.attlocal.net>
In-Reply-To: <CA+JQ7M9jBSB8tdpz85imER4SF1yhn3jes8ThnzkA_O9+mus1Ng@mail.gmail.com>

On 2022-06-24 13:23, Erik Cervin Edin wrote:

Show 5 quoted lines

> > 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

Derp, meant to type "--keep-index" there.

> 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.

That seems to be what I'm experiencing.

Show 7 quoted lines

> 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

Right, which is what I'd tried.  Except

  git stash

effectively takes a diff of HEAD..{working copy} and stashes that, while --keep-index also takes note of what was in the index.

My hope had been for an option to have git-stash use the index as its baseline rather than use HEAD.

Show 12 quoted lines

> 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

Yeah, those are among the issues I was bumping against. With different files, it's a little less troublesome. But when there might be some overlap, became problematic.

Show 8 quoted lines

> > 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)

Okay, based on the other replies, it sounds like it might be the most practical route to go since I'm not missing some existing functionality of git-stash.

Show 6 quoted lines

> > 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.

I don't find the speed an issue as much as I have trouble with any of the --patch variants that aren't `git add -p` because I'm never 100% positive which direction + vs - means. Which is partly why I wanted to stick with `add -p` and stash the non-staged stuff.

Show 5 quoted lines

> > 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.

Thanks! That's pretty much what I'm getting from the rest of the replies, too.

-Tim