{"thread":{"id":"31833","subject":"feature request","startedAt":"2012-10-16T11:36:04Z","lastAt":"2012-10-17T00:00:37Z","messageCount":6,"participants":["Angelo Borsotti","Andrew Ardill","Christian Thaeter","Sitaram Chamarty"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"201324","messageId":"CAB9Jk9AwTVM4TPwPg1Gmi8TCnnXWUsMAfaz8DdfcEhBNW_15Ug@mail.gmail.com","threadId":"31833","inReplyTo":null,"subject":"feature request","fromName":"Angelo Borsotti","fromEmail":"angelo.borsotti@gmail.com","sentAt":"2012-10-16T11:36:04Z","receivedAt":"2012-10-16T11:36:04Z","isPatch":false,"sender":{"key":"angelo.borsotti@gmail.com","avatar":null},"body":"Hello,\n\nsome VCS, e.g. ClearCase, allow to control the fetching of files so as\nto warn, or\ndisallow parallel changes to the same files.\nAs of today, there is no way to implement the same kind of workflow with git\nbecause there are no fetch hooks.\nWould it be a good idea to provide them?\n\n-Angelo Borsotti\n"},{"id":"201330","messageId":"CAH5451=1VU6oUzAyGXZvOW-Pk3+Os1mq1neum572venNjRfT+g@mail.gmail.com","threadId":"31833","inReplyTo":"CAB9Jk9AwTVM4TPwPg1Gmi8TCnnXWUsMAfaz8DdfcEhBNW_15Ug@mail.gmail.com","subject":"Re: feature request","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2012-10-16T12:15:00Z","receivedAt":"2012-10-16T12:15:00Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On 16 October 2012 22:36, Angelo Borsotti wrote:\n>\n> Hello,\n>\n> some VCS, e.g. ClearCase, allow to control the fetching of files so as\n> to warn, or\n> disallow parallel changes to the same files.\n> As of today, there is no way to implement the same kind of workflow with\n> git\n> because there are no fetch hooks.\n> Would it be a good idea to provide them?\n>\n> -Angelo Borsotti\n\nIt seems like you want to be able to lock a file for editing once\nsomeone has 'checked-out' the file. This really only makes sense for\nbinary files (or files which there is no straightforward way to merge)\nas otherwise you are throwing away the usefulness of git without any\ngain. Git is designed so that multiple people can work on a file at\nthe same time. Easy merging means that collating those changes is an\neasy task, and so locking a file has no use. If a file cannot be\neasily merged then it does make sense to lock the file. Is this what\nyou need to do, or is there some other reason for wanting a lock?\n\nIn any case, locking a file is a hard thing to do right in a\ndistributed system, and doesn't really make sense (although it may be\nuseful!) When you clone a git repository you have the entire history\nof the repository on your computer. What does it mean to have a locked\nfile? Does the file get deleted from everyone's repository every time\nsomeone else locks it? That would seem silly. Perhaps everyone simply\ncan't write to that file once it has been locked - how do you impose\nthat restriction in a distributed system (you can't)?\n\nInstead you can only refuse pushes that change the locked file (which\nis normal - you would have to force the push for any non fast-forward\nchanges), and you can try to warn users that somebody else has locked\nthe file. This warning system might be doable in some fashion, by\nusing hooks to write the locked files to a text file somewhere and\nchecking that, however it would be near impossible to get right or\nwould hamstring the distributed nature of git by forcing constant\nserver checks.\n\nInstead of continuing making the point here, let me point you towards\nsome other discussions around file locks, in particular how git\nhandles binary files. You should be able to find many more, but as a\nstarter, look at [1] and [2].\n\nIn general, I would reconsider why two users shouldn't be able to\nchange the same file at the same time.\n\nRegards,\n\nAndrew Ardill\n\n[1] http://stackoverflow.com/questions/119444/locking-binary-files-using-git-version-control-system\n[2] http://git.661346.n2.nabble.com/Lock-binairy-files-in-Git-td2422894.html\n"},{"id":"201332","messageId":"20121016153429.6e06ef91@jupiter.pipapo.org","threadId":"31833","inReplyTo":"CAB9Jk9AwTVM4TPwPg1Gmi8TCnnXWUsMAfaz8DdfcEhBNW_15Ug@mail.gmail.com","subject":"Re: feature request","fromName":"Christian Thaeter","fromEmail":"ct@pipapo.org","sentAt":"2012-10-16T13:34:29Z","receivedAt":"2012-10-16T13:34:29Z","isPatch":false,"sender":{"key":"ct@pipapo.org","avatar":null},"body":"Am Tue, 16 Oct 2012 13:36:04 +0200\nschrieb Angelo Borsotti :\n\n> Hello,\n> \n> some VCS, e.g. ClearCase, allow to control the fetching of files so as\n> to warn, or\n> disallow parallel changes to the same files.\n> As of today, there is no way to implement the same kind of workflow\n> with git because there are no fetch hooks.\n> Would it be a good idea to provide them?\n\n\nI've actually implemented a 'git lock' command to lock pathnames from\nconcurrent editing for a customer. Normally one would say this is a\nrather ill and ugly feature for git but there where some reasons to do\nit anyways (imagine robots crashing into each other on a production\nline because of bad (developer-)communication).\n\nThe code is GPL and I can distribute it, but I didn't consider it ready\nfor an open announcement yet. Noteworthy some problems with msys led\nto some ugly solution (the uniq command doesn't know the -z option\nthere).\n\nI hope this might be useful to you. I'd also like to get contributions\nand fixes if there are any problems I am not aware of.\n\nShort into; the doc:\n\n http://git.pipapo.org/?p=git;a=blob_plain;f=Documentation/git-lock.txt;h=dcc7a5c34dea657ab5819e8def54e154d5d97219;hb=25ee09cf35daa03a7c2ef10537561a50db2d17b2\n\nthe code is available at\n\n git://git.pipapo.org/git\n\nin the 'ct/git-lock' branch.\n\nIt is a bit fallen behind the current git version, I will update/merge\nit sometime next (to keep in par with msysgit, thats what is required\nhere)\n\n\tChristian\n\n\n\n\n> \n> -Angelo Borsotti\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"},{"id":"201369","messageId":"CAB9Jk9DaJnN9wmzi-4P3+PqBOobOapnU50y5zkKV9-1CNpV3Yw@mail.gmail.com","threadId":"31833","inReplyTo":"CAH5451=1VU6oUzAyGXZvOW-Pk3+Os1mq1neum572venNjRfT+g@mail.gmail.com","subject":"Re: feature request","fromName":"Angelo Borsotti","fromEmail":"angelo.borsotti@gmail.com","sentAt":"2012-10-16T17:27:26Z","receivedAt":"2012-10-16T17:27:26Z","isPatch":false,"sender":{"key":"angelo.borsotti@gmail.com","avatar":null},"body":"Hi Andrew,\n\none nice thing is to warn a developer that wants to modify a source\nfile, that there is somebody else changing it beforehand. It is nicer\nthan discovering that at push time.\nTake into account that there are changes in files that may be\nincompatible to each other, or that can be amenable to be\nautomatically merged producing wrong results. So, knowing it could\nhelp.\n\n-Angelo\n"},{"id":"201395","messageId":"CAMK1S_iRRLFmL33UcLRowbbJqG+JoJt011yg=R3s4MegE4_JbA@mail.gmail.com","threadId":"31833","inReplyTo":"CAB9Jk9DaJnN9wmzi-4P3+PqBOobOapnU50y5zkKV9-1CNpV3Yw@mail.gmail.com","subject":"Re: feature request","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2012-10-16T23:30:01Z","receivedAt":"2012-10-16T23:30:01Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On Tue, Oct 16, 2012 at 10:57 PM, Angelo Borsotti\n wrote:\n> Hi Andrew,\n>\n> one nice thing is to warn a developer that wants to modify a source\n> file, that there is somebody else changing it beforehand. It is nicer\n> than discovering that at push time.\n\nAndrew:\n\nalso see http://sitaramc.github.com/gitolite/locking.html for a way to\ndo file locking (and enforce it) using gitolite.\n\nThis does warn, as long as the user remembers to try to acquire a lock\nbefore working on a binary file. (You can't get around that\nrequirement on a DVCS, sorry!)\n\n> Take into account that there are changes in files that may be\n> incompatible to each other, or that can be amenable to be\n> automatically merged producing wrong results. So, knowing it could\n> help.\n>\n> -Angelo\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\n\n-- \nSitaram\n"},{"id":"201396","messageId":"CAH5451k4SQdbzx5euuFg2eNisiMXRG6jXGS76pbgqA+djoFy+A@mail.gmail.com","threadId":"31833","inReplyTo":"CAB9Jk9DaJnN9wmzi-4P3+PqBOobOapnU50y5zkKV9-1CNpV3Yw@mail.gmail.com","subject":"Re: feature request","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2012-10-17T00:00:37Z","receivedAt":"2012-10-17T00:00:37Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On 17 October 2012 04:27, Angelo Borsotti wrote:\n> Hi Andrew,\n>\n> one nice thing is to warn a developer that wants to modify a source\n> file, that there is somebody else changing it beforehand. It is nicer\n> than discovering that at push time.\n> Take into account that there are changes in files that may be\n> incompatible to each other, or that can be amenable to be\n> automatically merged producing wrong results. So, knowing it could\n> help.\n>\n> -Angelo\n\nIf you simply want to know when a file has been changed by someone\nelse, git already has this capability, but as you note it only occurs\nwhen you try to push. Unless you force push, you have to merge changes\nbefore committing to upstream. In a distributed situation you can only\ninform the user when they 'touch-base' with the server, and if that is\nwhat you want than one of the locking systems others have proposed\nmight be a good choice.\n\nThere are two concerns to deal with here. The first is when any\nconflicts at all will cause problems, as there is no way to merge\nthem. This often happens with binary files, and is a good reason to\nuse a locking system. The second concern is situations where a merge\nhappens 'silently' (i.e. no conflicts) thus allowing potential logic\nbugs to be introduced even though semantically the merge was fine. For\nthis situation the best option is to require whoever is merging to\ncheck the merge output for logical errors. This has to happen anyway,\nas it is possible for logical errors to be introduced across different\nfiles, although it's probably more common to see logic conflicts\nwithin the one file. To make it easier to discover such changes early\nin the process you could write a tool that did some (or all) of the\nfollowing:\n1. Automatically fetch changes from remote repositories at a regular interval.\n2. Compare files changed in the working tree and index to changes\nfetched from remote repositories. This would need to find the merge\nbase of the two and compare files touched since then.\n3. Notify the user of the files that have been changed through some fashion.\n4. Automatically push changes to a 'wip' branch so that others can see\nwhat you are modifying. Alternatively, automatically publish a list of\nchanged files for the same purpose, though this seems a lot more hacky\n(though both options are surely hacky).\n\n2 and 3 could be combined into a single tool run whenever the user\nwants to check for potential logic changes down the track. Automating\nit would allow for this information to be communicated a bit faster.\nRunning it after each fetch would be a nice to have. Pushing the work\nin progress branch is something I am not sure is a good idea, but it\nwould be the only way to know when someone else is working on\nsomething before they commit and push it manually. Pushing a single\nfile with files being worked on is less invasive, but would require\nthe other aspects of the tool to use it as well (hence forming a\nstronger coupling and reducing the usefulness of the other components\nas standalone tools).\n\n\nThere is no way that I know of to force merge to stop every time the\nfile is changed on both theirs and ours (regardless of whether or not\nit is an actual conflict or not). It could potentially be done with a\npre-merge hook, but no such hook exists to my knowledge. If this were\nimplemented, using it would make merging a potentially tiresome\naffair, however I could see its usefulness for people who were very\nconcerned about introducing logic errors with merges on the same file.\n\nThe best solution is in my opinion to check what is going to be merged\nbefore you merge it, but a tool to warn that someone else is modifying\nthe same file would have its uses.\n\nRegards,\n\nAndrew Ardill\n"}]}