{"thread":{"id":"29318","subject":"Mark and protect local commits?","startedAt":"2012-01-09T08:29:04Z","lastAt":"2012-01-09T09:55:32Z","messageCount":2,"participants":["norbert.nemec","Michael Haggerty"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"182152","messageId":"jee8ii$6ft$1@dough.gmane.org","threadId":"29318","inReplyTo":null,"subject":"Mark and protect local commits?","fromName":"norbert.nemec","fromEmail":"norbert.nemec@native-instruments.de","sentAt":"2012-01-09T08:29:04Z","receivedAt":"2012-01-09T08:29:04Z","isPatch":false,"sender":{"key":"norbert.nemec@native-instruments.de","avatar":null},"body":"Hi there,\n\nI have often wished that there were ways to\n\na) protect certain commits from leaving the local repository\n\nb) mark commits that have already left the local repository\n\n\nTo be more specific:\n\na) Sometimes, I try out certain experimental features and want to make \nsure they don't accidentally end up out in the wild. If there were a \nflag to explicitly mark them \"private\", any non-local operation (push, \npull, etc) on these commits could create an error message.\n\nb) For history-rewriting operations, it is important to know which \ncommits are out in the wild and which are not. In a \"push\"-setup working \ncopy, git should be able to keep track of this. Any newly created commit \nwould be marked as \"unpublished\" and the mark would be removed when the \ncommit is pushed. Any history-rewriting would be prevented on published \ncommits.\n\n\nHas anyone else thought along these lines?\n\nGreetings,\nNorbert\n"},{"id":"182157","messageId":"4F0AB994.4030702@alum.mit.edu","threadId":"29318","inReplyTo":"jee8ii$6ft$1@dough.gmane.org","subject":"Re: Mark and protect local commits?","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2012-01-09T09:55:32Z","receivedAt":"2012-01-09T09:55:32Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 01/09/2012 09:29 AM, norbert.nemec wrote:\n> I have often wished that there were ways to\n> \n> a) protect certain commits from leaving the local repository\n> \n> b) mark commits that have already left the local repository\n> \n> \n> To be more specific:\n> \n> a) Sometimes, I try out certain experimental features and want to make\n> sure they don't accidentally end up out in the wild. If there were a\n> flag to explicitly mark them \"private\", any non-local operation (push,\n> pull, etc) on these commits could create an error message.\n\nIn Subversion we solved this problem by having a local convention that\nthe central server forbids the commit of any files containing the magic\nstring \"@@@\".  This was enforced by a (server-side) pre-commit hook.\nThis allows developers to mark local hacks (e.g., debugging printfs)\nwith a comment containing the magic string, and Subversion would help\nprevent them from committing that code accidentally.  This feature is\npopular with developers.\n\nOne subtlety is that you don't want to enforce the file-contents check\non *every* file because the magic string could appear by chance in some\nkind of binary file.  We used svn properties to tell the system on which\nfiles to enforce the constraints.\n\nWhen we started using git-svn, we added a second (server-side) check:\nthat the magic string is not allowed in the commit message.  That way,\ndebugging commits can be made to the local git-svn-managed git\nrepository but prevented from being \"pushed\" to Subversion.\n\nWe have implemented something similar for git on the client side, using\n.gitattributes for its configuration.  But this is not quite the same.\nWhen using pure git, there are cases when you want local commits that\ncontain the forbidden string, but to prevent those commits from being\npushed.  For this, a server-side pre-update hook would be needed.  This,\nin turn, has the technical problem that until recently .gitattributes\nwere effectively unusable on the server.  So we haven't yet implemented\nthe analogous server-side hooks.\n\nAn alternative would be to have some kind of \"pre-push\" hook which could\ncarry out similar checks on the client.  This would allow individuals to\nimplement their own policy without requiring the central project to have\na pre-commit hook.  I don't believe that there is currently any such hook.\n\n> b) For history-rewriting operations, it is important to know which\n> commits are out in the wild and which are not. In a \"push\"-setup working\n> copy, git should be able to keep track of this. Any newly created commit\n> would be marked as \"unpublished\" and the mark would be removed when the\n> commit is pushed. Any history-rewriting would be prevented on published\n> commits.\n\nThis would be convenient, too.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"}]}