Handle git_path() with lock files correctly in worktrees
#401
Conversation
Without this, you cannot use `--run=<...>` to skip that part, and a run with `--run=0` (which is a common way to determine the test case number corresponding to a given test case title). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
force-pushed
the
lock-files-in-worktrees
branch
from
0bde197
to
f08c90e
Compare
|
/submit |
|
Submitted as pull.401.git.1571209637.gitgitgadget@gmail.com |
![gitgitgadget[bot]](https://avatars.githubusercontent.com/in/12836?s=60&v=4){kind=small}
dscho
force-pushed
the
lock-files-in-worktrees
branch
from
f08c90e
to
93dba5a
Compare
|
/submit |
|
Submitted as pull.401.v2.git.1571350077.gitgitgadget@gmail.com |
|
This branch is now known as |
|
This patch series was integrated into pu via git@5c3ead4. |
|
This patch series was integrated into pu via git@48502d2. |
|
This patch series was integrated into pu via git@e9e2058. |
dscho
force-pushed
the
lock-files-in-worktrees
branch
from
93dba5a
to
8b1f4f0
Compare
|
/submit |
|
Submitted as pull.401.v3.git.1571694882.gitgitgadget@gmail.com |
|
This patch series was integrated into pu via git@38fe1fc. |
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, and therefore so is its reflog). 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 `logs/HEAD.lock` file is constructed from
`git_path("logs/HEAD")` by appending the `.lock` suffix.
However, Git GUI just learned to use `--git-path` instead of appending
relative paths to what `git rev-parse --git-dir` returns (and as a
consequence not only using the correct hooks directory, but also using
the correct paths in worktrees other than the main one). While it does
not seem as if Git GUI in particular is asking for `logs/HEAD.lock`,
let's be safe rather than sorry.
Side note: Git GUI _does_ ask for `index.lock`, but that is already
resolved correctly, due to `update_common_dir()` preferring to leave
unknown paths in the (worktree-specific) git directory.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
force-pushed
the
lock-files-in-worktrees
branch
from
8b1f4f0
to
d988108
Compare
|
/submit |
|
Submitted as pull.401.v4.git.1572267438.gitgitgadget@gmail.com |
This comment has been minimized.
This comment has been minimized.
|
This patch series was integrated into pu via git@af2a863. |
|
This patch series was integrated into pu via git@6fe6fec. |
|
This patch series was integrated into pu via git@7c3951c. |
|
This patch series was integrated into pu via git@74393e7. |
|
This patch series was integrated into pu via git@0fd1045. |
|
This patch series was integrated into pu via git@6e6457e. |
|
This patch series was integrated into pu via git@29765d6. |
|
This patch series was integrated into pu via git@dcbbf86. |
|
This patch series was integrated into pu via git@2b65dbb. |
|
This patch series was integrated into pu via git@befc330. |
|
This patch series was integrated into pu via git@29cd43a. |
|
This patch series was integrated into next via git@b406944. |
|
This patch series was integrated into pu via git@48f9bda. |
|
This patch series was integrated into pu via git@1f121e3. |
|
This patch series was integrated into pu via git@80883c4. |
|
This patch series was integrated into pu via git@07e86b8. |
|
This patch series was integrated into pu via git@a126152. |
|
This patch series was integrated into pu via git@a2b0451. |
|
This patch series was integrated into next via git@a2b0451. |
|
This patch series was integrated into master via git@a2b0451. |
|
Closed via a2b0451. |
I stumbled over this during my recent work in Git GUI that was originally really only intended to use the correct hooks directory.
It turns out that my fears that
index.lockwas mishandled were unfounded, hence this patch series has a lot lower priority for me than "OMG we must push this into v2.24.0!".Technically, the first patch is not needed (because I decided against adding a test to
t1400in the end, in favor oft1500), but it shouldn't hurt, either.I verified locally that this patch pair does not conflict with
sg/dir-trie-fixes.Changes since v3:
.locksuffix, we now usestrbufmanipulation to strip the suffix temporarily.Changes since v2:
index.lock.trie_find()to special-case.lock, I now copy the string without the suffix.lock(if any) before handing it off totrie_find().Changes since v1:
index.lockis fine, it islogs/HEAD.lockthat isn't.