On Wed, Oct 5, 2011 at 12:46 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> 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. Git has survived w/o needing to lock branches till now. What are these use cases we cannot already think of today? > 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 don't think so. There are lots of ways to shoot yourself in the foot at the plumbing level. Besides, this is not about all refs, just local branches. Aside, there's nothing wrong with renaming a checked out branch. > 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? I think you mean create_symref()? Looking at it's callers that seems too low-level. Maybe you could sketch out how you think this should work, I'm not seeing it. - Where/how should the lock be recorded? - Which function(s) should record/release the lock? 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