From: Taylor Blau <me@ttaylorr.com>
To: Birk Tjelmeland <git@birktj.no>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] stash: show error message when lockfile is present
Date: Sun, 7 Nov 2021 22:21:39 -0500 [thread overview]
Message-ID: <YYiXw41upJfPS7l0@nand.local> (raw)
In-Reply-To: <20211107213012.6978-1-git@birktj.no>
On Sun, Nov 07, 2021 at 10:30:12PM +0100, Birk Tjelmeland wrote:
> Multiple git-stash commands silently fail when index.lock is present,
> including git stash push and git stash apply. This is somewhat confusing
> and a better behaviour would probably be to exit with a meaningful error
> message like most other git commands do.
We do terminate with non-zero exit code when trying to, for e.g., 'git
stash push' when $GIT_DIR/index.lock already exists. That is reflected
in your patch by not adding any new paths which we return, which makes
sense.
> This patch updates repo_refresh_and_write_index to accept another
> parameter lock_flags and updates some callsites of this function to call
> it with LOCK_REPORT_ON_ERROR resulting a suitable error message when the
> relevant git-stash commands used on a repo with an index.lock file.
>
> This patch only adds the described error message to git-stash commands,
> however the diff highlights other uses of repo_refresh_and_write_index
> which could also benefit from the changes. On the other hand these
> callsites already have some limited error messages.
I wonder if there are callers of repo_refresh_and_write_index() that
don't want any errors reported. Not having thought about it too hard
(much less looked through any of these callers), I would expect that
having the choice to either error() or die() is something worth keeping.
But I do not know if there are callers which want neither.
> Signed-off-by: Birk Tjelmeland <git@birktj.no>
> ---
> add-interactive.c | 4 ++--
> add-patch.c | 4 ++--
> builtin/am.c | 2 +-
> builtin/merge.c | 4 ++--
> builtin/stash.c | 6 +++---
> cache.h | 4 ++--
> read-cache.c | 3 ++-
> 7 files changed, 14 insertions(+), 13 deletions(-)
It looks like the sum-total of this patch are a few things:
- repo_refresh_and_write_index() gets a new lock_flags parameter which
is passed down to repo_hold_locked_index()
- refresh_and_write_cache() which is a thin wrapper around
repo_refresh_and_write_index() also learned the new parameter
- do_apply_stash(), do_create_stash(), do_push_stash() all pass
LOCK_REPORT_ON_ERROR via the new lock_flags parameter
That all makes sense to me. It results in us printing a helpful error
message when we couldn't acquire an exclusive lock on
$GIT_DIR/index.lock where before we would have silently failed and
exited non-zero (which is not exactly a *silent* failure, but it is
close).
This patch does not include any tests, which I think that you should add
in another revision before we consider queuing this.
Thanks,
Taylor
next prev parent reply other threads:[~2021-11-08 3:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-07 21:30 [PATCH] stash: show error message when lockfile is present Birk Tjelmeland
2021-11-08 3:21 ` Taylor Blau [this message]
2021-11-08 4:15 ` Taylor Blau
2021-11-08 7:10 ` Junio C Hamano
2021-11-08 17:56 ` Taylor Blau
2021-11-08 19:05 ` Ævar Arnfjörð Bjarmason
2021-11-08 20:05 ` Junio C Hamano
2021-11-08 20:35 ` Birk Tjelmeland
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=YYiXw41upJfPS7l0@nand.local \
--to=me@ttaylorr.com \
--cc=git@birktj.no \
--cc=git@vger.kernel.org \
/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.