[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    When someone creates a new worktree by copying an existing one
From:       Tao Klerks <tao () klerks ! biz>
Date:       2023-05-31 18:59:46
Message-ID: CAPMMpohHo2co7n_NjD9XntBs3DVU91Rqx8dmRrSWg=1eof+Rhw () mail ! gmail ! com
[Download RAW message or body]

Hi folks,

I've recently encountered some users who've got themselves into
trouble by copying a worktree into another folder, to create a second
worktree, instead of using "git worktree add".

They assumed this would be fine, just the same as creating a new
*repository* by copying an new *repository* is generally fine (except
when you introduce worktrees, of course).

There users eventually understood that something was wrong, as you
might expect, when a checkout in one worktree also "checked out" (and
produced lots of unexpected changes) in the other worktree - or
similar weirdnesses, eg on commit.

Ideally, as I user, I would expect git to start shouting at me to "git
worktree repair" the moment the mutual reference between the ".git"
file of the worktree, and the "gitdir" file of the repo's worktree
metadata, stopped agreeing.

Is there any reason we can't/don't have such a safety check? (would it
be expensive??)

I think I can implement something reasonably effective with a pair of
hooks (pre-commit and post-checkout look like good candidates), but
I'm weirded out that something like this should need to be "custom".

I did a quick search of the archives but didn't find anything
relevant. Has this been discussed? Should I try to prepare a patch
including that sort of validation... somewhere?

Thanks,
Tao
[prev in list] [next in list] [prev in thread] [next in thread]