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: [BUG] "git stash -- path" reports wrong unstaged changes
Date: Sat, 18 Mar 2017 18:36:58 +0000	[thread overview]
Message-ID: <20170318183658.GC27158@hank> (raw)
In-Reply-To: <20170317145039.dmcb3qyqbzfvtmgz@sigill.intra.peff.net>

On 03/17, Jeff King wrote:
> I used "git stash -- path" for the first time today and happened to
> notice an oddity. If I run:
> 
> 	git init -q repo
> 	cd repo
> 	
> 	for i in one two; do
> 		echo content >$i
> 		git add $i
> 	done
> 	git commit -qm base
> 	
> 	for i in one two; do
> 		echo change >$i
> 	done
> 	git stash -- one
> 
> it says:
> 
>   Saved working directory and index state WIP on master: 20cfadf base
>   Unstaged changes after reset:
>   M	one
>   M	two
> 
> Even though "one" no longer has unstaged changes.

Yeah, this is clearly not right.  Thanks for catching this before it
got into any release.

> If I run with GIT_TRACE=1, that message is generated by:
> 
>   git reset -- one
> 
> which makes sense. At that stage we've just reset the index, but the
> working tree file still has modifications. In the non-pathspec case we
> run "git reset --hard", which takes care of the index and the working
> tree.
> 
> It's really "checkout-index" that cleans the working tree, but it
> doesn't have porcelain finery like an "Unstaged changes" message. I
> think the patch below would fix it, but I wonder if we can do it in a
> way that doesn't involve calling diff-files twice.
> 
> -Peff
> 
> ---
> diff --git a/git-stash.sh b/git-stash.sh
> index 9c70662cc..9a4bb503a 100755
> --- a/git-stash.sh
> +++ b/git-stash.sh
> @@ -299,10 +299,15 @@ push_stash () {
>  	then
>  		if test $# != 0
>  		then
> -			git reset ${GIT_QUIET:+-q} -- "$@"
> +			git reset -q -- "$@"
>  			git ls-files -z --modified -- "$@" |
>  			git checkout-index -z --force --stdin
>  			git clean --force ${GIT_QUIET:+-q} -d -- "$@"
> +			if test -z "$GIT_QUIET" && ! git diff-files --quiet
> +			then
> +				say "$(gettext "Unstaged changes after reset:")"
> +				git diff-files --name-status
> +			fi
>  		else
>  			git reset --hard ${GIT_QUIET:+-q}
>  		fi

This would mean the user gets something like in your case above:

    Unstaged changes after reset:
     M	two

As a user that doesn't know the internal implementation of push_stash,
this would make me wonder why git stash would mention a file that is
not provided as pathspec, but not the one that was provided in the
pathspec argument.

I think one option would be to to just keep quiet about the exact
changes that git stash push makes, similar to what we do in the
--include-untracked and in the -p case.  The other option would be to
find the files that are affected and print them, but that would
probably be a bit too noisy especially in cases such as
git stash push -- docs/*.

Also from reading the code in the -p case, when --keep-index is given,
the git reset there doesn't respect $GIT_QUIET at all, and also
doesn't respect the pathspec argument, which seems like another bug.
I can submit a patch series for those, but I won't get to it before
tomorrow :)

  reply	other threads:[~2017-03-18 18:43 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 [this message]
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
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=20170318183658.GC27158@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.