All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.