On Thu, Jul 04, 2013 at 08:10:07PM +0200, Ævar Arnfjörð Bjarmason wrote: > On Thu, Jul 4, 2013 at 7:56 PM, Thomas Koch <thomas@xxxxxxx> wrote: > > we're evaluating Git to be used in our companies Tool. But a hard requirement > > is the possibility to set an "intend-to-edit" flag on a file (better path). > > Notice that I did not use the word "lock"! :-) > > > > One easy implementation might be a special branch "XYZ-locks" that contains an > > empty blob for every flagged file. So our tool just needs to check, whether a > > blob exists for the path that's intended to edit, tries to push a commit that > > touches the file and only allows editing if the push succeeds. > > In my experience everyone who thinks this is a hard requirement is > wrong. I completely agree with this. Having said that, if you're looking at using Gitolite (which you should if you're hosing your own repositories and not using some other hosting solution), there is a "lock" command [1]. Note that this cannot stop you committing changes to "locked" files locally but it does stop you pushing changes to the central repository that touch locked files. [1] http://gitolite.com/gitolite/locking.html -- 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