From: Junio C Hamano <gitster@pobox.com>
To: Thomas Gummerer <t.gummerer@gmail.com>
Cc: git@vger.kernel.org, kes-kes@yandex.ru
Subject: Re: [RFC] stash: support filename argument
Date: Sun, 15 Jan 2017 16:21:42 -0800 [thread overview]
Message-ID: <xmqqvatfc0rt.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20170115142542.11999-1-t.gummerer@gmail.com> (Thomas Gummerer's message of "Sun, 15 Jan 2017 14:25:42 +0000")
Thomas Gummerer <t.gummerer@gmail.com> writes:
> While working on a repository, it's often helpful to stash the changes
> of a single or multiple files, and leave others alone. Unfortunately
> git currently offers no such option. git stash -p can be used to work
> around this, but it's often impractical when there are a lot of changes
> over multiple files.
>
> Add a --file option to git stash save, which allows for stashing a
> single file. Specifying the --file argument multiple times allows
> stashing more than one file at a time.
>
> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
> ---
>
> Marked as RFC and without documentation updates to first get a feeling
> for the user interface, and whether people are interested in this
> change.
>
> Ideally I wanted the the user interface to look like something like:
> git stash save -- [<filename1,...>], but unfortunately that's already
> taken up by the stash message. So to preserve backward compatibility
> I used the new --file argument.
I haven't spent enough time to think if it even makes sense to
"stash" partially, leaving the working tree still dirty. My initial
reaction was "then stashing away the dirty WIP state to get a spiffy
clean working environment becomes impossible", and I still need time
to recover from that ;-) So as to the desirablity of this "feature",
I have no strong opinion for or against yet.
But if we were to do this, then we should bite the bullet and
declare that "stash save <message>" was a mistake. It should have
been "stash save -m <message>" and we should transition to that (one
easy way out would be to find another verb that is not 'save').
Then we can do "git stash save [-m <msg>] [--] [pathspec...]" which
follows the usual command line convention.
next prev parent reply other threads:[~2017-01-16 0:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-15 14:25 [RFC] stash: support filename argument Thomas Gummerer
2017-01-16 0:21 ` Junio C Hamano [this message]
2017-01-16 0:41 ` Stephan Beyer
2017-01-16 8:18 ` Marc Strapetz
2017-01-16 23:49 ` Jeff King
2017-01-16 10:51 ` Johannes Schindelin
2017-01-16 13:14 ` Johannes Schindelin
2017-01-16 22:29 ` Thomas Gummerer
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=xmqqvatfc0rt.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=kes-kes@yandex.ru \
--cc=t.gummerer@gmail.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 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.