From: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Nadav Goldstein via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org,
Nadav Goldstein <nadav.goldstein96@gmail.com>
Subject: Re: [PATCH] Add 'preserve' subcommand to 'git stash'
Date: Fri, 16 Jun 2023 22:03:56 +0200 [thread overview]
Message-ID: <ZIzALOe8GBsNGIhR@ugly> (raw)
In-Reply-To: <xmqqjzw3qry6.fsf@gitster.g>
On Fri, Jun 16, 2023 at 09:42:41AM -0700, Junio C Hamano wrote:
>"Nadav Goldstein via GitGitGadget" <gitgitgadget@gmail.com> writes:
>> In this patch, we introduce a new subcommand preserve to
>> git stash. The purpose of this subcommand is to save the
>> current changes into the stash and then immediately re-apply
>> those changes to the working directory.
>
>Why a new subcommand, not a new option to "push"? Adding a new
>subcommand would mean it would be another unfamiliar thing users
>need to learn, as opposed to a slight variation of what they are
>already familiar with.
>
to be fair, there's also `apply` and not `pop --keep`.
of course, `preserve` seems a bit unspecific, but `save` and `create`
are already taken.
>> If the community will approve, I will modify the patch to include
>> help
>> messages for the new subcommand
>
>Please don't think this way. If the new feature is not worth
>completing to document and tests for your own use, it is not worth
>community's time to review or "approve" it.
>
for one's own use, one usually wouldn't do the polishing.
>Instead, we try to send a patch that is already perfected, with tests
>and docs,
>
it's nice when "we" do that, but i think that this is a somewhat too
one-sided committment to *ask* for.
>in order to improve the chance reviewers will understand the new
>feature and its motivation better when they review the patch.
>
i think one can achieve that without doing the full monty.
that's what the design-driven process is for, after all. the crux is at
what contribution size one considers it "worth it", but you can be sure
that drive-by contributors have a significantly lower threshold than
regulars.
i'm not saying that nadav succeeded, but a focus on final artifacts
alone is unlikely to have changed anything.
regards,
ossi
next prev parent reply other threads:[~2023-06-16 20:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-16 11:00 [PATCH] Add 'preserve' subcommand to 'git stash' Nadav Goldstein via GitGitGadget
2023-06-16 16:42 ` Junio C Hamano
2023-06-16 20:03 ` Oswald Buddenhagen [this message]
2023-06-16 20:11 ` Junio C Hamano
2023-06-17 8:39 ` Oswald Buddenhagen
2023-06-17 11:21 ` Junio C Hamano
2023-06-18 9:05 ` Nadav Goldstein
2023-06-18 9:47 ` Oswald Buddenhagen
2023-06-18 10:57 ` Nadav Goldstein
2023-06-19 1:42 ` Junio C Hamano
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=ZIzALOe8GBsNGIhR@ugly \
--to=oswald.buddenhagen@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=nadav.goldstein96@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.