Re: Locking binary files

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 23, 2008, 19:49 UTC
Message-ID: <7v7i92tzgb.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <alpine.LNX.1.00.0809231216350.19665@iabervon.org>

Daniel Barkalow <barkalow@iabervon.org> writes:

Show 5 quoted lines

> 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.