Re: [RFC/PATCH] Add multiple workdir support to branch/checkout

[Junio C Hamano <gitster@pobox.com>]

Jay Soffian <jaysoffian@gmail.com> writes:

> On Wed, Oct 5, 2011 at 12:02 AM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>> Could you please consider a more generic approach? What I have in mind
>> is a mechanism to "lock" a branch, so that only commands that have the
>> key can update it.
>>
>> So instead of branch.<name>.checkout, I would have something like
>> branch.<name>.locked = <key>, where <key> is just a string. Only
>> commands that provide the matching <key> are allowed to update the
>> branch. In checkout case, <key> could be "checkout: worktree".
>
> In this case, each workdir needs its own key, so I'd have to record
> the key somewhere, unless you meant using a key of "checkout:
> </path/to/workdir>".

That actually is how I read his message.

I do not think "we cannot off the top of our heads think of the reason
other than the branch is checked out that we might want to forbid its
update" is a very good excuse to cast the word "checkout" in the UI; you
would paint yourself in a difficult corner that you have to expend more
energy to get out of by later adding backward compatibility support.

I think "switch_branches()" that updates HEAD to point at a local branch
is one good place to lock the branch, but I do not know if it is a good
idea to hook the check into the codepaths for deletion of the branch using
"branch -[dD]" and check-out of the branch using "checkout $branch". I
wonder if it makes sense to add the "checking" hook into much lower level
in the callchain, perhaps delete_ref(), rename_ref() and update_ref() to
catch attempts to update "your" current branch by other people. For that
matter, instead of switch_branches(), would it make more sense to add this
lock/unlock logic to symbolic_ref() that repoints HEAD to other branch?