> It should be easy for a company to set a policy where a couple of scripts > must be run for particular type of files. Given that, the implementation > of such scripts is easy: > > For every foo.bin there is possibly a foo.bin.lock file. > > Lock-script look for absence of the lock-file at upstream then git-add > the file (With some info that tells users things like who has the file). > If git-push fails, since I'm adding a file and someone already added > it while I was pushing, then the lock is not granted. > > Unlock-script will git-rm the lock-file and push. > > In both scripts mod-bits of original file can be toggled for > read-only/write signaling to the user. (At upstream the file is always > read-only) > > This can also work in a distributed system with more then one tier of > servers. (Locks pushed to the most upstream server) > > Combine that with git's mail notifications for commits and you have a > system far more robust then svn will ever want to be > > My $0.017 > Boaz > This is a reasonable approach to obtaining the desired functionality. Unfortunately, I have not seen any third-party packages implementing such a feature. It seems to me the problem is general enough to be solved once rather than requiring organizations wishing to use git to implement an in-house locking system. It simply creates more friction. Perhaps, when I have the time, I will come up with something others can use. For now, unfortunately, it seems I am out of luck? Mario -- 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
