From: David Aguilar <davvid@gmail.com>
To: git@vger.kernel.org
Cc: gitster@pobox.com, nanako3@lavabit.com, kevinlsk@gmail.com
Subject: Resurrecting an old git-stash discussion
Date: Sun, 3 May 2009 18:35:55 -0700 [thread overview]
Message-ID: <20090504013554.GE50640@gmail.com> (raw)
A long time ago there was a patch that made git-stash
configurable:
http://lists.zerezo.com/git/msg641406.html
Junio's conclusion at the time was:
"The decision here is that I am open to a change that
implements the one-time safety instruction."
http://lists.zerezo.com/git/msg641442.html
Would this be something worth implementing after this
release cycle?
If so, would this be the basic logic?:
If stash.quick is undefined:
- Alert the user to what's going on
- Ask them whether they'd like to enable the quick behavior,
or exit (thus leaving stash.quick undefined).
Valid values for stash.quick are then either undefined
or 'save'.
Is it still a good idea to implement the one-time
safety instruction?
I just thought I'd ask. Why?
A co-worker ran into this funny situation last week:
git branch
git stash # oops, didn't mean that
git stash help # prints usage, though only by luck
git branch help # oops, didn't mean that
There's a limit to guarding against the uneducated and by no
means do I think the 2nd "oops"'s behavior should be changed.
With the proposed change we would've warned him at the first
"oops", and that's better than nothing.
The above is a silly example despite the fact that it
actually happened. 'rm help' happily removes your 'help'
file. I just figured I'd mention it since maybe instead of
printing usage stash should also warn:
Error: unknown command 'help'.
Run 'git help stash' for more information.
Regarding the 'first time warning' thing:
97bc00a: Emit helpful status for accidental "git stash" save
..seems like it already addressed the issue by telling
users how to apply the stash. That makes the case for
the first-time-warning much less compelling.
Hmm.. maybe I just answered my own question ;)
The "unknown command 'help'" thing might be good nonetheless,
though.
--
David
reply other threads:[~2009-05-04 1:38 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20090504013554.GE50640@gmail.com \
--to=davvid@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=kevinlsk@gmail.com \
--cc=nanako3@lavabit.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).