{"thread":{"id":"34953","subject":"Locking files / git","startedAt":"2013-09-17T19:45:26Z","lastAt":"2013-09-18T21:12:47Z","messageCount":7,"participants":["Nicolas Adenis-Lamarre","Jeff King","Fredrik Gustafsson","Thomas Koch","Sitaram Chamarty"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"227780","messageId":"CACPGbcsB-ieZnS5maQgtnRTifFON9fEFpCGGdHtQ2ZjySdxDYA@mail.gmail.com","threadId":"34953","inReplyTo":null,"subject":"Locking files / git","fromName":"Nicolas Adenis-Lamarre","fromEmail":"nicolas.adenis.lamarre@gmail.com","sentAt":"2013-09-17T19:45:26Z","receivedAt":"2013-09-17T19:45:26Z","isPatch":false,"sender":{"key":"nicolas.adenis.lamarre@gmail.com","avatar":null},"body":"Ooops. It seems that each time somebody says these two words together,\npeople hate him, and he is scorned by friends and family.\n\nHowever,\n- gitolite implement it (but gitolite is not git).\n- In the documentation, each time the need is evocated, it is replace\nby \"do communication, don't use git for that\". I'm still looking for\nthe good way to communicate this information. In my humble opinion,\ngit is a communication tool.\nI won't explain here why it could be a if not good, at least helpfull\nnew feature (and everybody is not mandatory to use new feature),\nI've still heard no argument about why it could not be accepted in git\nbetter than \"locking is bad\".\nI want to explain how I could implement it.\n\nFirstly, it would (in the general form ; some options could be added)\nalter no existing command of git.\nIt would add 3 new commands :\n- git lock [path]\n- git unlock [path]\n- git lslock\n\nIt would add 2 new files in .git :\n- lockserver containing a ssh url of the git repository, not necessary\nthe source of the clone (in fact, the same content of the lockserver\nfile in the source of the clone so that people gets the same lock\nserver)\n- lockedfiles containing the list of pathes of locked files (plus name\nof the people locking, date) on the lock server.\n\ngit push would not be altered, however, you can imagine an option to\nunlock all locked files by yourself.\n\nthe 3 new commands would require a communication to the lock server.\nnote that the idea is that everybody get the same lock server in any workflow.\nIn case there was no server defined on the original git repository,\nyou have to communicate so that people configure the lockserver file.\n\ngit lock would put the path provided into the lock server\ngit unlock would remove the path provided from the lock server\ngit lslock would ask pathes to the lock server\n\nYou must have rules on your project, for example, lock a .doc file\neach time you modify it.\nIf you follow that guideline, you’ll be fine. If you don’t, people\nwill hate you, and you’ll be scorned by friends and family.\nIf you push a file which is not locked by you, any problem, it will\npush (eventually, telling you that the file was locked and that your\nproject has some rules).\n\nWhat about automatic unlocking to prevent from forgetting to unlock :\nSomething like pushing when the push server is the same as the lock\nserver could automatically unlock the file.\nThe question is when to unlock when you have a complex workflow with a dictator.\nI agree i've not the best answer for the moment. Something like when\nthe developper have the files back, identically from the source of the\ndictator. This point could be think more.\n\nScenario :\n@alice : git lock src/main.c\n@bob : git lock src/main.c\nfatal: file src/main.c locked by alice\n@alice : git unlock src/main.c\n@bob : git lock src/main.c\n\nFor the moment, i want a first feedback, an intermediate between\n\"locking is bad\" and \"ok\", but i would prefer in the negativ answer\nsomething with arguments (\"Take CVS as an example of what not to do;\nif in doubt, make the exact opposite decision.\" is one), and in the\npositiv answer, good remarks about problems with my implementation\nthat could make it better.\n\nPerhaps this subject has already been discussed and is closed, in this\ncase, sorry, just give me the link i've not found please.\n\nNicolas Adenis-Lamarre\n"},{"id":"227799","messageId":"20130917210047.GD16860@sigill.intra.peff.net","threadId":"34953","inReplyTo":"CACPGbcsB-ieZnS5maQgtnRTifFON9fEFpCGGdHtQ2ZjySdxDYA@mail.gmail.com","subject":"Re: Locking files / git","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-09-17T21:00:48Z","receivedAt":"2013-09-17T21:00:48Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Sep 17, 2013 at 09:45:26PM +0200, Nicolas Adenis-Lamarre wrote:\n\n> Ooops. It seems that each time somebody says these two words together,\n> people hate him, and he is scorned by friends and family.\n\nAnd strangers on mailing lists. :)\n\n> However,\n> - gitolite implement it (but gitolite is not git).\n\nYes, and I think that distinction is important.\n\nLocking is fundamentally about having a centralized server. Even if you\nhave some decentralization (e.g., let's imagine two divisions of a\ncompany that work as peers), the whole point of the lock is that\nmultiple people are communicating with the same lock server (so in that\nsame example, from the perspective of people in those divisions, there\nis a central server for each division, and that would be the lock\nserver).\n\nGit itself does not know know or care about your workflow, and whether\nthe remote you are pushing to is central or not. Having a lock server\nwould be unlike the rest of git.\n\nWhereas gitolite, since it is about managing access to a centralized\nrepository, is a good place to handle locking.\n\nIn other words, I do not think locking is inherently bad. It is only\nthat it is useful for a subset of workflows that git provides. So I\ndon't think that git is the right place to implement it; rather it\nshould be built on top, either standalone or as part of other tools that\nalready assume some centralization.\n\n> I want to explain how I could implement it.\n> [...]\n\nThat all sounds like a reasonable workflow, but I think you could just\nas easily implement it on top of git.\n\nIn particular, the protocol does not have any room to communicate this\ndata. So you are already going out-of-band over ssh, or something\nsimilar. The only support you need from git is to auto-unlock the files\nafter a push. And I think you could do that using a post-receive hook.\nAnd indeed, you would not want git itself to do it anyway, because the\nrules for when to unlock are going to depend on your workflow (e.g.,\nwhich branches a commit must hit to trigger an unlock).\n\n-Peff\n"},{"id":"227803","messageId":"20130917213619.GM28675@paksenarrion.iveqy.com","threadId":"34953","inReplyTo":"CACPGbcsB-ieZnS5maQgtnRTifFON9fEFpCGGdHtQ2ZjySdxDYA@mail.gmail.com","subject":"Re: Locking files / git","fromName":"Fredrik Gustafsson","fromEmail":"iveqy@iveqy.com","sentAt":"2013-09-17T21:36:19Z","receivedAt":"2013-09-17T21:36:19Z","isPatch":false,"sender":{"key":"iveqy@iveqy.com","avatar":"https://avatars.githubusercontent.com/u/761743?v=4"},"body":"On Tue, Sep 17, 2013 at 09:45:26PM +0200, Nicolas Adenis-Lamarre wrote:\n> Ooops. It seems that each time somebody says these two words together,\n> people hate him, and he is scorned by friends and family.\n> \n> For the moment, i want a first feedback, an intermediate between\n> \"locking is bad\" and \"ok\", but i would prefer in the negativ answer\n> something with arguments (\"Take CVS as an example of what not to do;\n> if in doubt, make the exact opposite decision.\" is one), and in the\n> positiv answer, good remarks about problems with my implementation\n> that could make it better.\n\nSo working with locks and text-files is generally stupid to do with git\nsince you don't use git merging capabilities. Working with binary files\nin git is stupid because git doesn't handle them very well because they\nthe deltas can't be calculated very good.\n\nIt seems to me that if you need to do locking one of the above scenarios\nis true for you and you should not use git at all.\n\nHowever, there's always the case when you've a mixed project with both\nbinary and text-files. In that case I believe Jeff gave an excellent answer.\n\nBut think twice, are you using git in a sane way? Even a small binary\nfile will result in a huge git repo if it's updated often and the\nproject has a long history.\n\n-- \nMed vänliga hälsningar\nFredrik Gustafsson\n\ntel: 0733-608274\ne-post: iveqy@iveqy.com\n"},{"id":"227831","messageId":"CACPGbcv+w=p+Zk_+djL8ONEWN4LfDNbeVbxcpk-TJX=B3To=gg@mail.gmail.com","threadId":"34953","inReplyTo":"20130917213619.GM28675@paksenarrion.iveqy.com","subject":"Re: Locking files / git","fromName":"Nicolas Adenis-Lamarre","fromEmail":"nicolas.adenis.lamarre@gmail.com","sentAt":"2013-09-18T10:12:50Z","receivedAt":"2013-09-18T10:12:50Z","isPatch":false,"sender":{"key":"nicolas.adenis.lamarre@gmail.com","avatar":null},"body":"Thanks a lot for your answer.\nThat's really good arguments that i was waiting for and that i have\nnot get until now.\n\nMy comprehension now :\n- it's not easy to maintain several versions of a binary file in parallel.\nSo basically, it's not recommanded to have complex workflow for binary files.\nIn case the project has a low number of binary files, it can be handle\nby simple communication,\nIn case the project has a lot of binary files, a simple workflow with\na centralized workflow is recommanded\n- git doesn't hate locks, it's just that it's not the layer to\nimplement it because git is workflow independant. Locks depend on a\ncentralized server which is directly linked to the workflow.\n\nI'm not trying to implement a such workflow. I'm just curious, reading\na lot of things about git, and trying to understand what is sometimes\ncalled a limitation of git.\nA simple line in the documentation to say that locking should be\nhandled in the upper layer (and it's done for example in gitolite)\nbecause it's dependant of the workflow could help some people looking\nabout that point.\n\nThanks a lot for git.\n\n2013/9/17 Fredrik Gustafsson <iveqy@iveqy.com>:\n> On Tue, Sep 17, 2013 at 09:45:26PM +0200, Nicolas Adenis-Lamarre wrote:\n>> Ooops. It seems that each time somebody says these two words together,\n>> people hate him, and he is scorned by friends and family.\n>>\n>> For the moment, i want a first feedback, an intermediate between\n>> \"locking is bad\" and \"ok\", but i would prefer in the negativ answer\n>> something with arguments (\"Take CVS as an example of what not to do;\n>> if in doubt, make the exact opposite decision.\" is one), and in the\n>> positiv answer, good remarks about problems with my implementation\n>> that could make it better.\n>\n> So working with locks and text-files is generally stupid to do with git\n> since you don't use git merging capabilities. Working with binary files\n> in git is stupid because git doesn't handle them very well because they\n> the deltas can't be calculated very good.\n>\n> It seems to me that if you need to do locking one of the above scenarios\n> is true for you and you should not use git at all.\n>\n> However, there's always the case when you've a mixed project with both\n> binary and text-files. In that case I believe Jeff gave an excellent answer.\n>\n> But think twice, are you using git in a sane way? Even a small binary\n> file will result in a huge git repo if it's updated often and the\n> project has a long history.\n>\n> --\n> Med vänliga hälsningar\n> Fredrik Gustafsson\n>\n> tel: 0733-608274\n> e-post: iveqy@iveqy.com\n"},{"id":"227856","messageId":"201309182106.04413.thomas@koch.ro","threadId":"34953","inReplyTo":"CACPGbcsB-ieZnS5maQgtnRTifFON9fEFpCGGdHtQ2ZjySdxDYA@mail.gmail.com","subject":"Re: Locking files / git","fromName":"Thomas Koch","fromEmail":"thomas@koch.ro","sentAt":"2013-09-18T19:06:04Z","receivedAt":"2013-09-18T19:06:04Z","isPatch":false,"sender":{"key":"thomas@koch.ro","avatar":null},"body":"On Tuesday, September 17, 2013 09:45:26 PM Nicolas Adenis-Lamarre wrote:\n> Ooops. It seems that each time somebody says these two words together,\n> people hate him, and he is scorned by friends and family.\n\nSee the thread \"intend-to-edit flag\" for one implementation idea:\n\nhttp://git.661346.n2.nabble.com/intend-to-edit-flag-td7591127.html\n"},{"id":"227865","messageId":"523A1564.2080107@gmail.com","threadId":"34953","inReplyTo":"CACPGbcsB-ieZnS5maQgtnRTifFON9fEFpCGGdHtQ2ZjySdxDYA@mail.gmail.com","subject":"Re: Locking files / git","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2013-09-18T21:04:36Z","receivedAt":"2013-09-18T21:04:36Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 09/18/2013 01:15 AM, Nicolas Adenis-Lamarre wrote:\n> Ooops. It seems that each time somebody says these two words together,\n> people hate him, and he is scorned by friends and family.\n> \n> However,\n> - gitolite implement it (but gitolite is not git).\n\nNo.  It pretends to implement it, for people who absolutely must have\nsomething and are willing to play by the rules.\n\nQuoting from the doc [1], \"When git is used in a truly distributed\nfashion, locking is impossible\".\n\nI wrote it as a sort of bandaid, and that is all it is.  \"Implement\" is\ntoo kind a word.\n\nregards\n\nsitaram\n"},{"id":"227866","messageId":"523A174F.4030905@gmail.com","threadId":"34953","inReplyTo":"CACPGbcv+w=p+Zk_+djL8ONEWN4LfDNbeVbxcpk-TJX=B3To=gg@mail.gmail.com","subject":"Re: Locking files / git","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2013-09-18T21:12:47Z","receivedAt":"2013-09-18T21:12:47Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 09/18/2013 03:42 PM, Nicolas Adenis-Lamarre wrote:\n> Thanks a lot for your answer.\n> That's really good arguments that i was waiting for and that i have\n> not get until now.\n> \n> My comprehension now :\n> - it's not easy to maintain several versions of a binary file in parallel.\n> So basically, it's not recommanded to have complex workflow for binary files.\n> In case the project has a low number of binary files, it can be handle\n> by simple communication,\n\nYes.  Since you mentioned gitolite in your original post, I assume you\nread this caution also in the doc [1]:\n\n    \"Of course, locking by itself is not quite enough. You may still get\n    into merge situations if you make changes in branches. For best\n    results you should actually keep all the binary files in their own\n    branch, separate from the ones containing source code.\"\n\nThe point is that locking and distribution don't go together at all.\nThe **core** of distributed VCS is the old \"coding on an airplane\"\nstory.  What if someone locks a file after I am in the air, and I manage\nto get in a good 4 hours of solid work?\n\nCVCSs can also get into this situation, but to a lesser extent, I think.\nAt least you won't be able to commit!\n\n[1]: http://gitolite.com/gitolite/locking.html\n\n> In case the project has a lot of binary files, a simple workflow with\n> a centralized workflow is recommanded\n> - git doesn't hate locks, it's just that it's not the layer to\n> implement it because git is workflow independant. Locks depend on a\n> centralized server which is directly linked to the workflow.\n> \n> I'm not trying to implement a such workflow. I'm just curious, reading\n> a lot of things about git, and trying to understand what is sometimes\n> called a limitation of git.\n\nIt's not a limitation of git.  It's a fundamental conflict between the\nidea of \"distributed\" and what locking necessitates.\n\n> A simple line in the documentation to say that locking should be\n> handled in the upper layer (and it's done for example in gitolite)\n> because it's dependant of the workflow could help some people looking\n> about that point.\n\nFor people who don't realise how important the \"D\" in DVCS is, and\nassume some sort of a central server will always exist, this \"simple\nline\" won't do.  You'd have to explain all of that.\n\nAnd for people who do understand it, it's not necessary :-)\n\n> Thanks a lot for git.\n> \n> 2013/9/17 Fredrik Gustafsson <iveqy@iveqy.com>:\n>> On Tue, Sep 17, 2013 at 09:45:26PM +0200, Nicolas Adenis-Lamarre wrote:\n>>> Ooops. It seems that each time somebody says these two words together,\n>>> people hate him, and he is scorned by friends and family.\n>>>\n>>> For the moment, i want a first feedback, an intermediate between\n>>> \"locking is bad\" and \"ok\", but i would prefer in the negativ answer\n>>> something with arguments (\"Take CVS as an example of what not to do;\n>>> if in doubt, make the exact opposite decision.\" is one), and in the\n>>> positiv answer, good remarks about problems with my implementation\n>>> that could make it better.\n>>\n>> So working with locks and text-files is generally stupid to do with git\n>> since you don't use git merging capabilities. Working with binary files\n>> in git is stupid because git doesn't handle them very well because they\n>> the deltas can't be calculated very good.\n>>\n>> It seems to me that if you need to do locking one of the above scenarios\n>> is true for you and you should not use git at all.\n>>\n>> However, there's always the case when you've a mixed project with both\n>> binary and text-files. In that case I believe Jeff gave an excellent answer.\n>>\n>> But think twice, are you using git in a sane way? Even a small binary\n>> file will result in a huge git repo if it's updated often and the\n>> project has a long history.\n>>\n>> --\n>> Med vänliga hälsningar\n>> Fredrik Gustafsson\n>>\n>> tel: 0733-608274\n>> e-post: iveqy@iveqy.com\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n> \n"}]}