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

  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.