Daniel Barkalow <barkalow@xxxxxxxxxxxx> writes: > I think the right tool on the git side is actually a "smudge/clean" > script. When you check something out, git converts it from the > repository-stored form to a working tree form using a script (if there is > one configured); this could check whether you've got the appropriate lock, > and make the file unwritable if you don't. An obvious question is "how would such a script check the lock when you are 30,000 ft above ground"; in other words, this "locking mechanism" contradicts the very nature of distributed development theme. The best mechanism should always be on the human side. An SCM auguments inter-developer communication, but it is not a _substitute_ for communication. But if you limit the use case to an always tightly connected environment (aka "not distributed at all"), I agree the above would be a very reasonable approach. Such a setup would need a separate locking infrastructure and an end user command that grabs the lock and when successful makes the file in the work tree read/write. The user butchers the contents after taking the lock, saves, and then when running "git commit", probably the post-commit hook would release any relevant locks. All these can be left outside the scope of git, as they can be hooked into git with the existing infrastructure. Once a BCP materializes it could be added to contrib/ just like the "paranoid" update hook. -- 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
