Re: Locking binary files

Mario, please don't reply in private. That way your mails won't get indexed and you don't have a chance to get help from others on the mailing list.

While we're at it; don't top-post. Most people who frequent email lists with moderate to high traffic read hundreds of emails every day, so a quick reminder of what the discussion was about is useful when getting a reply. That reminder gets a lot trickier to get to if you first have to scroll down and then back up. Besides that, it feels totally backwards.

Mario Pareja wrote:

So it's a communication issue then. The way I understand locks in svn and cvs is that they also only bother you when you want to check in the file you've just recently modified, or if multiple people want to lock the same file at the same time.

If that's the case, I see no problem what so ever with teaching specific git commands to interact with a locking server. git lock (and git unlock) would have to be coupled with a git-lock-daemon with wich everyone communicates. It should probably have the ability to run a hook or something (centrally) when a lock is obtained and released, so as to be able to notify others that a lock is held.

I might write this for fun some day, but it's really not my itch to scratch, and it would be a terrible mistake to add something like a central repository to take care of it when a single rather stupid daemon and an equally stupid program could do the same work but much more efficiently.

Note that locking would be completely advisory though, and nothing would prevent people from committing changes to a locked file. Then again, insofar as I understand SVN/CVS locking, that's how those work too, except that an SVN "checkin" would be the equivalent of "git commit && git push" (the push part of the git sequence won't work).