{"thread":{"id":"65489","subject":"Re: [RFC] worktree: add --recurse-submodules support to git worktree add","startedAt":"2026-04-15T15:12:53Z","lastAt":"2026-04-15T15:12:53Z","messageCount":1,"participants":["Jimmy Aguilar Mena"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"541660","messageId":"ad-pAL9wDZ-KDfcn@RTX","threadId":"65489","inReplyTo":null,"subject":"Re: [RFC] worktree: add --recurse-submodules support to git worktree add","fromName":"Jimmy Aguilar Mena","fromEmail":"kratsbinovish@gmail.com","sentAt":"2026-04-15T15:12:48Z","receivedAt":"2026-04-15T15:12:53Z","isPatch":false,"body":"\nPhillip,\n\nGood catch — let me clarify what the script actually places on disk.\n\nThe hardlink copy does not go into $GIT_COMMON_DIR/modules/ (which\nboth worktrees would then share). It goes into each worktree's own\ngitdir entry:\n\ncp -al $GIT_COMMON_DIR/modules \\\n        $GIT_COMMON_DIR/worktrees/$id/modules\n\nSo worktree A uses $GIT_COMMON_DIR/modules/sub/ and worktree B uses\n$GIT_COMMON_DIR/worktrees/B/modules/sub/ — these are physically\nseparate directory trees with separate paths.\n\nWithin those trees the files start out as hardlinks (same inode), but\nthat only affects disk space accounting. It does not mean the data is\nshared. Git writes files atomically by writing to a lock file and then\ncalling rename(2), which gives the path a new inode. So the first time\ngit touches HEAD, index, or any ref in one worktree's submodule\ngitdir, the rename breaks that hardlink and the file becomes\nindependent. The other worktree's copy is untouched.\n\nThe only files that stay hardlinked forever are pack files and loose\nobject files — precisely because git objects are immutable by\ndesign. Two pack files with the same content should share the same\ndisk blocks; there is no correctness issue.\n\nThe net effect is the same separation git worktree already provides\nfor the outer repo (HEAD and index under\n$GIT_COMMON_DIR/worktrees/$id/, objects shared under\n$GIT_COMMON_DIR/objects/), but achieved through the filesystem rather\nthan explicit gitdir configuration. A native --recurse-submodules\nimplementation should do the same thing explicitly — probably by\nrunning the equivalent of git -C <sub-gitdir> worktree add for each\nsubmodule, which would give each submodule its own proper worktrees/\nstructure rather than relying on the hardlink + rename behaviour.\n\n\nSigned-off-by: Jimmy Aguilar Mena kratsbinovish@gmail.com\n"}]}