Duy Nguyen <pclo...@gmail.com> writes:
>> I am not happy with the choice of "main/HEAD" that would squat on a
>> good name for remote-tracking branch (i.e. s/origin/main/), though.
>> $GIT_DIR/COMMON_HEAD perhaps?
>
> It's not just about HEAD. Anything worktree-specific of the main
> checkout can be accessed this way, e.g. main/index,
> main/FETCH_HEAD.... and it's not exactly "common" because it's
> worktree info. Maybe 1ST_ as the prefix (e.g. 1ST_HEAD, 1ST_index...)
> ?
Do we even need to expose them as ref-like things as a part of the
external API/UI in the first place? For end-user scripts that want
to operate in a real or borrowing worktree, there should be no
reason to touch this "other" repository directly. Things like "if
one of the wortrees tries to check out a branch that is already
checked out elsewhere, error out" policy may need to consult the
other worktrees via $GIT_COMMON_DIR mechanism but at that level we
have all the control without contaminating end-user facing ref
namespace in a way main/FETCH_HEAD... do. You said
This makes it possible for a linked checkout to detach HEAD of
the main one.
but I think that is misguided---it just makes it easier to confuse
users, if done automatically and without any policy knob. It instead
should error out, while saying which worktree has the branch in
question checked out. After all, checking out a branch that is
checked out in another worktree (not the common one) needs the same
caution, so "main/HEAD" is not the only special one.
And if your updated "git checkout 'frotz'" gives a clear report of
which worktree has the branch 'frotz' checked out, the user can go
there to detach the HEAD in that worktree to detach with
git -C $the_other_one checkout HEAD^0
if he chooses to.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
