"Johannes Schindelin via GitGitGadget" <gitgitgad...@gmail.com>
writes:
> From: Johannes Schindelin <johannes.schinde...@gmx.de>
>
> Ever since worktrees were introduced, the `git_path()` function _really_
> needed to be called e.g. to get at the path to `logs/HEAD` (`HEAD` is
> specific to the worktree). However, the wrong path is returned for
> `logs/HEAD.lock`.
>
> This does not matter as long as the Git executable is doing the asking,
> as the path for that `index.lock` file is constructed from
> `git_path("index")` by appending the `.lock` suffix.
Is this still git_path("index") or is it now HEAD?
> Side note: Git GUI _does_ ask for `index.lock`, but that is already
> resolved correctly.
Is that s/but/and/?
> diff --git a/path.c b/path.c
> index e3da1f3c4e..ff85692b45 100644
> --- a/path.c
> +++ b/path.c
> @@ -268,7 +268,7 @@ static int trie_find(struct trie *root, const char *key,
> match_fn fn,
> int result;
> struct trie *child;
>
> - if (!*key) {
> + if (!*key || !strcmp(key, ".lock")) {
We only do strcmp for the tail part at the end of the path, so this
should probably OK from performance point of view but semantically
it is not very satisfying to see a special case for a single .suffix
this deep in the callchain. I wonder if it is nicer to have the
higher level callers notice ".lock" or whatever other suffixes they
care about and ask the lower layer for a key with the suffix
stripped?
Will queue.
Thanks.
