Jay Soffian <jaysoffian@xxxxxxxxx> writes: > On Wed, Oct 5, 2011 at 12:02 AM, Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> 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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html