On Thu, Oct 6, 2011 at 3:46 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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. That's what I meant. > 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. I'd aim at low-level ref manipulation because too me it affects more than just "git checkout". > 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? Couldn't find symbolic_ref() in current code. If you meant create_symref(), yes that would make sense. -- Duy -- 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