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>". > This approach addresses more cases than just multiple workdir. We > could relax restrictions on pushing to a non-bare repository: we only > disallow pushing to locked branches. Isn't that another case where you only care if the branch is checked out and where? So using "branch.<name>.checkout = </path/to/workdir>" should be fine there too. > We can also use this to prevent > users from checking out another branch (by locking HEAD) while in the > middle of interactive rebase/bisect/... I dunno, that seems like a really different use case. j. -- 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