git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Tim Chase <git@tim.thechases.com>
To: git@vger.kernel.org
Subject: Re: stashing only unstaged changes?
Date: Fri, 24 Jun 2022 15:38:04 -0500	[thread overview]
Message-ID: <20220624153804.44089117@bigbox.attlocal.net> (raw)
In-Reply-To: <CA+JQ7M9jBSB8tdpz85imER4SF1yhn3jes8ThnzkA_O9+mus1Ng@mail.gmail.com>

On 2022-06-24 13:23, Erik Cervin Edin wrote:
> > 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.

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

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

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

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

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






  reply	other threads:[~2022-06-24 21:03 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
2022-06-24 20:38   ` Tim Chase [this message]
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=20220624153804.44089117@bigbox.attlocal.net \
    --to=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).