All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gummerer <t.gummerer@gmail.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH/RFC 3/3] stash: pass the pathspec argument to git reset
Date: Tue, 21 Mar 2017 21:14:24 +0000	[thread overview]
Message-ID: <20170321211424.GE27158@hank> (raw)
In-Reply-To: <20170320190843.aw3fsenjvcek7a44@sigill.intra.peff.net>

On 03/20, Jeff King wrote:
> On Sun, Mar 19, 2017 at 08:23:51PM +0000, Thomas Gummerer wrote:
> 
> > For "git stash -p --no-keep-index", the pathspec argument is currently
> > not passed to "git reset".  This means that changed that are staged but
> > that are excluded from the pathspec still get unstaged by git stash -p.
> 
> Yeah, I noticed this while playing around with patch 2. This seems
> like an improvement to me. Unlike the other patches (which are just
> tweaking quietness), I think this one really needs a test.
>
> Also, s/changed/changes/ above.

Thanks.  Will add a test in the re-roll.

> > ---
> > So this make things a bit inconsistent in for example the following
> > situation:
> > 
> >     $ git status -s
> >      M git-stash.sh
> >     M  read-cache.c
> > 
> > where using git stash -p --no-keep-index, when only changes in
> > git-stash.sh are added to the stash would reset read-cache.c, but with
> > git stash -p --no-keep-index -- git-stash.sh, read-cache.c would not
> > be reset.
> 
> I think it's OK. You can't select (or not select) changes from the index
> anyway. TBH, I kind of wonder if "git stash -p --no-keep-index" makes
> any sense at all.

Yeah I don't have any use case for it, but maybe someone does, so I
think fixing it this way now is the best way forward.

> > However it does bring things more in line with git stash --
> > <pathspec>, so I think this is an improvement.
> 
> I did notice one other case while looking at this that I think is much
> more serious. The "read-tree" call in the non-patch-mode case doesn't
> use a pathspec either. So if we have our same setup where "one" and
> "two" have unstaged changes and we do:
> 
>   git stash push -k one
> 
> Then we stash "one", but the change in "two" is wiped out completely!

Good catch, that's definitely another bug :/ 

> I don't think read-tree takes pathspecs, so it would have to drop the
> "-u" and replace it with checkout-index. I'm confused about why we would
> need it in the first place, though. We should have already dealt with
> the working tree files in the earlier block, so there should be nothing
> to checkout.
> 
> The "-u" goes all the way back to 7bedebcaa (stash: introduce 'stash
> save --keep-index' option, 2008-06-27). I wonder if it has always been
> unnecessary, but we never noticed because it's just a noop.

I do think the "-u" is necessary.  Say we have a repository with
changes in 'foo' and 'bar', where the changes in bar are added to the
index.

Then 'git stash -k' would wipe out the changes in both 'foo' and 'bar'
through 'git reset --hard', but we do want the changes in 'bar' to
still exist on disk, which they wouldn't without the "-u".

But I'll replace the "-u" with checkout-index, so we can respect the
pathspec.

Thanks!

> -Peff

  reply	other threads:[~2017-03-21 21:14 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-17 14:50 [BUG] "git stash -- path" reports wrong unstaged changes Jeff King
2017-03-18 18:36 ` Thomas Gummerer
2017-03-19 20:23   ` Thomas Gummerer
2017-03-19 20:23     ` [PATCH/RFC 1/3] stash: show less information for stash push -- <pathspec> Thomas Gummerer
2017-03-20 17:51       ` Junio C Hamano
2017-03-20 18:48         ` Jeff King
2017-03-20 19:42           ` Junio C Hamano
2017-03-21 20:48             ` Thomas Gummerer
2017-03-20 18:42       ` Jeff King
2017-03-19 20:23     ` [PATCH/RFC 2/3] stash: make push -p -q --no-keep-index quiet Thomas Gummerer
2017-03-20 18:55       ` Jeff King
2017-03-19 20:23     ` [PATCH/RFC 3/3] stash: pass the pathspec argument to git reset Thomas Gummerer
2017-03-20 19:08       ` Jeff King
2017-03-21 21:14         ` Thomas Gummerer [this message]
2017-03-21 22:12           ` Jeff King
2017-03-21 22:12     ` [PATCH v2 0/3] Re: [BUG] "git stash -- path" reports wrong unstaged changes Thomas Gummerer
2017-03-21 22:12       ` [PATCH v2 1/3] stash: don't show internal implementation details Thomas Gummerer
2017-03-21 22:14         ` Jeff King
2017-03-22 21:33           ` Thomas Gummerer
2017-03-22 21:41             ` Jeff King
2017-03-21 22:12       ` [PATCH v2 2/3] stash: pass the pathspec argument to git reset Thomas Gummerer
2017-03-21 22:19         ` Jeff King
2017-03-21 22:12       ` [PATCH v2 3/3] stash: keep untracked files intact in stash -k Thomas Gummerer
2017-03-21 22:38         ` Jeff King
2017-03-22 21:46           ` Thomas Gummerer
2017-03-20 18:41   ` [BUG] "git stash -- path" reports wrong unstaged changes Jeff King

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

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

  git send-email \
    --in-reply-to=20170321211424.GE27158@hank \
    --to=t.gummerer@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.