git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Maksim Odnoletkov <odnoletkov@mail.ru>
Cc: gitster@pobox.com, git@vger.kernel.org, keithbsmiley@gmail.com
Subject: Re: [PATCH] Make stashing nothing exit 1
Date: Thu, 23 May 2019 02:23:44 +0200	[thread overview]
Message-ID: <871s0quigf.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <20190522235705.68452-1-odnoletkov@mail.ru>


On Thu, May 23 2019, Maksim Odnoletkov wrote:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> Keith Smiley <keithbsmiley@gmail.com> writes:
>>
>> > In the case there are no files to stash, but the user asked to stash, we
>> > should exit 1 since the stashing failed.
>> > ---
>>
>> Sorry, but I fail to see why this is a good change.  Did you have
>> some script that wanted the exit code from "git stash" to indicate
>> if it had anything to stash and change the behaviour based on it?
>>
>> Is it a big enough hassle to figure out if the "stash" command did
>> something yourself that justifies forcing existing scripts that rely
>> on "no-op is merely a normal exit" behaviour other people have
>> written in the past several years?
>
> The problem with current behaviour is it makes it hard to use stash in
> scripts. A natural stash use case is: wrap some operation requiring a
> clean working tree with a stash push-pop pair. But that doesn't work
> properly when working tree is already clean - push silently does nothing
> and following pop becomes unbalanced. You have to keep that in mind and
> work around with something like:
>
> if ! git diff-index --exit-code --quiet HEAD
> then
> 	git stash push
> 	trap 'git stash pop' EXIT
> fi
>
> With this change this can be simplified to:
>
> git stash push && trap 'git stash pop' EXIT
>
> I don't mind keeping this new behaviour behind an option for
> compatibility. Or alternatively resolve this use case by supporting
> --allow-empty in stash-push. But my feeling is it is natural for 'git
> stash push' to report error for no-op case because the command is
> explicitly about creating new stash entries. A close analogy is 'git
> commit' which errors on no-op. Contrary all commands treating no-op as a
> success I'm aware of are not about creating new objects but about
> querying or syncing.

I view "stash push" more like just "push", or even a special case for
"reset --hard", in both of those cases we don't exit non-zero if there's
nothing to do, i.e. if there's nothing to push, or if "reset --hard"
ends up needing to do nothing.

On the other hand as you point out it can also be viewed as "create new
stash entry", just like "create new commit", and we error out on that.

In practice I bet there's very few scripters of "git commit" that don't
want to actually create a commit, whereas "stash push" is more likely to
be used like "reset --hard", i.e. just "wipe/save-wipe changes if
needed".

I don't mind an --exit-code for it, or even a change in the default
behavior, just pointing out that it's a bit more nuanced than just a
missing exit code, given "push", "reset" etc. prior art.

  reply	other threads:[~2019-05-23  0:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-22 23:12 [PATCH] Make stashing nothing exit 1 Keith Smiley
2019-03-23  7:54 ` Ævar Arnfjörð Bjarmason
2019-03-24  3:37   ` Eric Sunshine
2019-03-25 15:29     ` Johannes Schindelin
2020-04-12 13:08   ` Maxim Mazurok
2019-03-24 12:42 ` Junio C Hamano
2019-05-22 23:57   ` Maksim Odnoletkov
2019-05-23  0:23     ` Ævar Arnfjörð Bjarmason [this message]
2019-05-23  6:14     ` Johannes Sixt
2019-05-23  9:49       ` Maksim Odnoletkov

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871s0quigf.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=keithbsmiley@gmail.com \
    --cc=odnoletkov@mail.ru \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).