From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>, git@vger.kernel.org
Subject: Re: Behaviour of 'git stash show' when a stash has untracked files
Date: Sun, 24 Sep 2017 09:41:31 +0900 [thread overview]
Message-ID: <xmqqing9hqro.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20170921033152.4hbkctzxraww5rqo@sigill.intra.peff.net> (Jeff King's message of "Wed, 20 Sep 2017 23:31:52 -0400")
Jeff King <peff@peff.net> 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).
next prev parent reply other threads:[~2017-09-24 0:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-17 5:27 Behaviour of 'git stash show' when a stash has untracked files Kaartic Sivaraam
2017-09-20 5:33 ` Junio C Hamano
2017-09-20 19:36 ` Jeff King
2017-09-21 1:23 ` Junio C Hamano
2017-09-21 3:31 ` Jeff King
2017-09-23 7:11 ` Kaartic Sivaraam
2017-09-24 0:41 ` Junio C Hamano [this message]
2017-09-23 7:03 ` Kaartic Sivaraam
-- strict thread matches above, loose matches on Subject: below --
2017-09-17 5:07 Kaartic Sivaraam
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=xmqqing9hqro.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=kaarticsivaraam91196@gmail.com \
--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.