Jay Soffian <jaysoffian@xxxxxxxxx> writes: > Git has survived w/o needing to lock branches till now. Careful. Git has survived without your patch series till now, as people learned to be careful when they use separate workdirs and avoid certain things, to the point that they are not necessarily aware that they are avoiding them (one good practice is to keep the HEADs of non-primary workdirs detached). Does that mean what your patch aims to do is unnecessary? I think not. > What are these > use cases we cannot already think of today? What is important is that we should have learned by now that the "gotchas" live where we do not immediately see. "Can you tell me what you are missing?" is a senseless thing to ask. >> 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. There are pros and cons between hooking at lower level vs higher level. The advantage of hooking at higher level is you do not risk breaking low-level operations, but that directly results in allowing the same low level operations that are unaware of the new requirement higher level added break it. It also allows other high level operations you forgot to teach the new requirement break it. For example, you checkout branch frotz in a workdir, and then in the primary repository that has nitfol branch checked out, you rename the frotz branch to xyzzy. The HEAD of workdir still says refs/heads/frotz that no longer exist. Of course you can break the same way by doing a "update-ref -d refs/heads/frotz" from the primary repository. Because you forgot that the high level operation "branch renaming" needs to be aware of that "this branch is checked out elsewhere" information, you allowed it to break the workdir. If you hooked into lower level machinery that is shared, you wouldn't have caused this breakage. Similarly, if delete_ref() were taught about the new requirement, you would have covered both "branch -d" and "update-ref -d". I do not necessarily think that it is a good approach to forbid the same branch to be checked out in two different places, by the way. One reason people would want to keep multiple workdirs is so that while they are still working on a branch and are not yet at a good "stop point" to even make a temporary commit to get interrupted, they find it sometimes necessary to be able to build the tip of that same branch and even make a small in-working-tree fixes (which later will be carried back to the primary branch). The problem arises only when one of the repositories try to update or delete the branch while it is checked out in another working tree. Can this series be extended/reworked so that: - Each branch has multi-value configuration record to note the workdirs that it is checked out; - Error out (or warn if forced) upon any attempt to update the tip of a branch that is checked out in more than one place; and - Similarly for renaming or deleting a branch that is checked out in more than one place. -- 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