git-gui: default to full copy for linked worktrees

git-gui's default clone method is git-clone's default, and this uses
hardlinks rather than copying the objects directory for local
repositories. However, this method explicitly fails if a symlink (or
.gitfile) exists in the path to the objects directory. Thus, the default
clone option fails for worktrees created by git-new-workdir or
git-worktree.  git-gui's original do_clone trapped this error for a
symlinked git-new-workdir tree, directly falling back to a full clone,
while the updated git-gui using git-clone does not. (The old do_clone
could not handle gitfile linked worktrees, however).

Let's apply the more friendly fallback to a full clone in both these
cases where git-clone behavior throws an error on the default method.

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
This commit is contained in:
Mark Levedahl
2025-07-21 11:12:18 -04:00
parent 6ff8d68ec1
commit 3ce650f4c9

View File

@@ -557,6 +557,25 @@ method _update_clone {args} {
method _do_clone2 {} {
if {[file isdirectory $origin_url]} {
set origin_url [file normalize $origin_url]
if {$clone_type eq {hardlink}} {
# cannot use hardlinks if this is a linked worktree (.gitfile or git-new-workdir)
if {[git -C $origin_url rev-parse --is-inside-work-tree] == {true}} {
set islink 0
set dotgit [file join $origin_url .git]
if {[file isfile $dotgit]} {
set islink 1
} else {
set objdir [file join $dotgit objects]
if {[file exists $objdir] && [file type $objdir] == {link}} {
set islink 1
}
}
if {$islink} {
info_popup [mc "Hardlinks are unavailable. Falling back to copying."]
set clone_type full
}
}
}
}
if {$clone_type eq {hardlink} && ![file isdirectory $origin_url]} {