Kaartic Sivaraam [off-list ref] writes:
Some time ago, I stashed a few changes along with untracked files. I
almost forgot it until recently. Then I wanted to see what I change I
had in the stash. So I did a 'git stash show <num>'. It worked fine but
didn't say anything about the untracked files in that stash. That made
me wonder where the untracked files I added went. I then applied the
stash to see that they were still there but weren't listed in show.
I understand that they aren't listed because 'git stash show' is
typically a "diff between the stashed state and its original parent" as
the documentation says but shouldn't there be at least a message that
the stash contains untracked files? Those untracked files are "part of
the stash" and I see no way to get information about their presence
currently.
So, should this behaviour be changed?
Hmm, crickets tell us that nobody is all that interested in this, it
seems. I do not think I'd be against a new feature that lets users
ask what untracked paths are in the stash (and even their contents),
but I do think it is a bad idea to change a vanilla "stash show" to
show that information in addition to what is currently shown.
Two things need to be designed carefuly. One is the UI to _invoke_
the new feature, the other is the output from the new feature.
As to the invocation, an obvious pair of choices are:
- "git stash show-untracked stash@{0} [ [--] <pathspec>]"?
- "git stash show --untracked stash@{0} [ [--] <pathspec>]"?
I'd personally vote for the former, if only because the latter makes
the design more complicated. For one thing, tying the feature to
"show" means the output _must_ be in the form of "diff" output in
order to be consistent with the normal output from the subcommand,
but a whole-file creation diff may not be the best way to show the
entire contents of an untracked file. Also by adding it as an
option to the existing "show" command, it makes it debatable if the
output should show the contents of untracked files in addition to
the stashed changes of tracked paths, or in place of them. Because
I suspect that viewing contents of the untracked files and the
changes to tracked paths may serve quite different purposes from the
point of view of expected use cases, I am leaning towards saying
that it is a bad idea to show contents of untracked paths in
addition to changes to tracked paths. There probably are other
reasons why we should prefer the former, i.e. a separate subcommand
to "git stash", independent of the existing "git stash show".
Assuming that we choose to go with a separate command, the output
format from the command does not have to be in the form of patch, so
perhaps "git stash show-untracked --list" may be a way to list the
paths (and we may want -z to show the list NUL-terminated like
"ls-files" does)? There may be other operations to help those who
want a way to learn about untracked paths in a stash. But this is
not exactly my itch so I'll let people who do have the itch to work
on designing the details out.
On Wed, Sep 20, 2017 at 02:33:04PM +0900, Junio C Hamano wrote:
Kaartic Sivaraam [off-list ref] writes:
quoted
Some time ago, I stashed a few changes along with untracked files. I
almost forgot it until recently. Then I wanted to see what I change I
had in the stash. So I did a 'git stash show <num>'. It worked fine but
didn't say anything about the untracked files in that stash. That made
me wonder where the untracked files I added went. I then applied the
stash to see that they were still there but weren't listed in show.
I understand that they aren't listed because 'git stash show' is
typically a "diff between the stashed state and its original parent" as
the documentation says but shouldn't there be at least a message that
the stash contains untracked files? Those untracked files are "part of
the stash" and I see no way to get information about their presence
currently.
So, should this behaviour be changed?
Hmm, crickets tell us that nobody is all that interested in this, it
seems.
Or sometimes people are just really behind in reading the mailing list. ;)
This seemed familiar, and indeed there was some discussion a few months
ago:
https://public-inbox.org/git/CAOtcWM3mrQEqDnjMipzea7Kp+VueBFsZDL2zcJ=y0wgj9N4Vjw@mail.gmail.com/
I sketched out a possible solution in:
https://public-inbox.org/git/20170317141417.g2oenl67k74nlqrq@sigill.intra.peff.net/
though I share your concerns over whether people would be annoyed to see
the existing "stash show" output changed.
-Peff
On Wed, 2017-09-20 at 15:36 -0400, Jeff King wrote:
Or sometimes people are just really behind in reading the mailing list. ;)
This seemed familiar, and indeed there was some discussion a few months
ago:
https://public-inbox.org/git/CAOtcWM3mrQEqDnjMipzea7Kp+VueBFsZDL2zcJ=y0wgj9N4Vjw@mail.gmail.com/
I sketched out a possible solution in:
https://public-inbox.org/git/20170317141417.g2oenl67k74nlqrq@sigill.intra.peff.net/
It seems I should have searched the list without being lazy before I
sent this one. Anyways, the output of the patch there sound a little
interesting.
though I share your concerns over whether people would be annoyed to see
the existing "stash show" output changed.
Though I'm not sure whether people would be annoyed about the change in
output, I personally find it a little odd to show the contents of
untracked files as if they have been "added" to the index (although
there is notice that these are "untracked-files"). I think that might
puzzle some users.
That said, when I actually sent this mail I was thinking of an
implementation of the following sort (thanks Peff!),
diff --git a/git-stash.sh b/git-stash.sh
index 8b2ce9afd..b79adc138 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -401,7 +401,10 @@ show_stash () {
fi
fi
- git diff ${FLAGS} $b_commit $w_commit
+ {
+ git diff ${FLAGS} $b_commit $w_commit
+ test -n "$u_commit" && git show --pretty=format:'%nUntracked files: ' ${FLAGS} $u_commit -- .
+ } | git_pager
}
show_help () {
I would like to turn this off when patch mode is requested, but I
currently couldn't. I would also like to print only the names of the
files, if possible.
I find this kind of output better than showing nothing at all or
showing the output of untracked files in the form of a diff when patch
mode is requested. IOW, this satisfies my expectation though I'm not
sure how much this would be useful to others.
---
Kaartic