From: Junio C Hamano <gitster@pobox.com>
To: Deveshi Dwivedi <deveshigurgaon@gmail.com>
Cc: git@vger.kernel.org, ben.knoble@gmail.com, mroik@delayed.space,
quentin.bernet@bluewin.ch
Subject: Re: [PATCH v3] stash: infer "push" when push-specific options are given
Date: Thu, 09 Apr 2026 13:22:34 -0700 [thread overview]
Message-ID: <xmqqecknsx2t.fsf@gitster.g> (raw)
In-Reply-To: <20260405110953.3316-1-deveshigurgaon@gmail.com> (Deveshi Dwivedi's message of "Sun, 5 Apr 2026 11:09:53 +0000")
Deveshi Dwivedi <deveshigurgaon@gmail.com> writes:
> +test_expect_success 'assume push when options imply push' '
> + git reset --hard &&
> + echo changed >file &&
> + git add file &&
> + git stash -m "implied push" file &&
> + git stash pop &&
> +
> + git add file &&
> + git stash --staged file &&
> + git stash pop &&
> +
> + git add file &&
> + git stash --keep-index file &&
> + git stash pop &&
> +
> + echo untracked >untracked-file &&
> + git stash --include-untracked untracked-file &&
> + test_path_is_missing untracked-file &&
A comment on these three lines.
> + git stash pop &&
> + rm -f untracked-file &&
> + git reset --hard
> +'
> +
I suspect that they are meant to be "clean-up after we are done with
the test, to avoid interfering with the next test", but if so,
"clean-up at the very end" is not a very effective strategy to do
so. Imagine that one of the previous steps fails, breaking all
later commands in the &&- cascade. Sitting at the very end, your
clean-up sequence will not run. Unless the tester is running this
test script with the "-i" option, the test will move on to the next
piece. Installing clean-up handler with test_when_finished may be
a cleaner approach.
test_expect_success 'do this test' '
test_when_finished "git stash clear; git reset --hard" &&
git reset --hard &&
... do all the dirty things in the working tree ...
test_when_finished "rm -f untracked-file" &&
echo untracked >untracked-file &&
git stash --include-untracked untracked-file &&
test_path_is_missing untracked-file
'
You can use more than one test_when_finished in a single test.
It is often done to add an upfront blunt hammer at the beginning to
do a clean-up without worrying too much about where exactly in the
command sequence a breakage may happen (e.g., we may fail before we
run our first "git add", or "git stash", and "git reset --hard" or
"git stash clear" may be an unnecessary no-op, but we do not worry
too much about the clean-up step doing potentially unnecessary
things.
Or you would set up a clean-up handler immediately before you create
a thing that you want to make sure you clean up. If the command
sequence fails before you echo the string into untracked-file to
create it, there is no point preparing to remove it when you are
done.
Both approaches are commmonly used.
> test_expect_success 'stash --invalid-option' '
> echo bar5 >file &&
> echo bar6 >file2 &&
>
> base-commit: 2855562ca6a9c6b0e7bc780b050c1e83c9fcfbd0
next prev parent reply other threads:[~2026-04-09 20:22 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-04 14:36 [PATCH] stash: infer "push" when push-specific options are given Deveshi Dwivedi
2026-04-04 15:19 ` Mirko Faina
2026-04-04 16:03 ` [PATCH v2] " Deveshi Dwivedi
2026-04-04 23:40 ` Mirko Faina
2026-04-05 7:02 ` Deveshi Dwivedi
2026-04-05 11:09 ` [PATCH v3] " Deveshi Dwivedi
2026-04-06 18:15 ` Mirko Faina
2026-04-07 9:36 ` Phillip Wood
2026-04-09 19:22 ` Deveshi Dwivedi
2026-04-09 19:37 ` Mirko Faina
2026-04-09 20:31 ` Junio C Hamano
2026-04-09 20:22 ` Junio C Hamano [this message]
2026-04-12 19:52 ` [PATCH v4] stash: infer "push" when command line starts with an option Deveshi Dwivedi
2026-04-13 9:08 ` Phillip Wood
2026-04-13 15:09 ` Junio C Hamano
2026-04-19 16:54 ` [PATCH v5] stash: assume " Deveshi Dwivedi
2026-04-21 15:28 ` Phillip Wood
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=xmqqecknsx2t.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=ben.knoble@gmail.com \
--cc=deveshigurgaon@gmail.com \
--cc=git@vger.kernel.org \
--cc=mroik@delayed.space \
--cc=quentin.bernet@bluewin.ch \
/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