-
Notifications
You must be signed in to change notification settings - Fork 141
Handle git_path()
with lock files correctly in worktrees
#401
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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 <[email protected]>
0bde197
to
f08c90e
Compare
/submit |
Submitted as [email protected] |
f08c90e
to
93dba5a
Compare
/submit |
Submitted as [email protected] |
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. |
93dba5a
to
8b1f4f0
Compare
/submit |
Submitted as [email protected] |
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 <[email protected]>
8b1f4f0
to
d988108
Compare
/submit |
Submitted as [email protected] |
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.lock
was 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
t1400
in 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:
.lock
suffix, we now usestrbuf
manipulation 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.lock
is fine, it islogs/HEAD.lock
that isn't.