Thread (1 message) 1 message, 1 author, 2017-09-24

Re: Behaviour of 'git stash show' when a stash has untracked files

From: Junio C Hamano <hidden>
Date: 2017-09-24 00:41:38

Jeff King [off-list ref] writes:
I think it would mostly Just Work for your case. git-apply should ignore
the subject cruft at the top of the patch. And if you didn't create a
stash with "-u" or with bits in the index, then those would be absent
from the diff.

And if you _did_ create such a stash, I actually suspect that "apply"
barfing on the resulting patch may be a better outcome than silently
ignoring the changes.
OK, that sounds sensible.
I dunno. I do not use either of those features ("-u" or stashing the
index state) myself. But I have always been bothered how the saved state
is a bit hidden from the user. It seems like a recipe for user confusion
when they save something with "git stash" but then "stash show" doesn't
even mention it.
Yes, I do not dispute that the issue needs to be addressed.  What I
was unsure was how (e.g. should that be given always? does the user
ask and if so how? what the output to tell the information looks
like?)
Those all seem like sane interface proposals. As I said above, I have a
vague feeling that the default _ought_ to tell about everything.
OK.
I guess the nuclear option there is introducing "git stash info" or
something, and marking "git stash show" as an alias for "git stash info
--worktree". It is too bad, though, as "show" is really the perfect
name.
I think the end result of that becomes the same as adding "git stash
info" an alias for "git stash show --all" on top of what I wrote.

I suspect nobody uses "stash show" in a script in such a way that
its output is consumed by the script logic, so it may probably be OK
to show everything by default (which I agree is the way we would
have done _if_ people demanded on day 1 that we need to record all
three variants; IIRC, in the early days of the command back when the
"show" subcommand appeared, even "--index" was merely an intellectual
curiosity and was not a serious feature, and from that point of view
the historical output we currently have made sense).
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help