Jeff King <peff@xxxxxxxx> 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).
