On 01/09/2012 09:29 AM, norbert.nemec wrote: > I have often wished that there were ways to > > a) protect certain commits from leaving the local repository > > b) mark commits that have already left the local repository > > > To be more specific: > > a) Sometimes, I try out certain experimental features and want to make > sure they don't accidentally end up out in the wild. If there were a > flag to explicitly mark them "private", any non-local operation (push, > pull, etc) on these commits could create an error message. In Subversion we solved this problem by having a local convention that the central server forbids the commit of any files containing the magic string "@@@". This was enforced by a (server-side) pre-commit hook. This allows developers to mark local hacks (e.g., debugging printfs) with a comment containing the magic string, and Subversion would help prevent them from committing that code accidentally. This feature is popular with developers. One subtlety is that you don't want to enforce the file-contents check on *every* file because the magic string could appear by chance in some kind of binary file. We used svn properties to tell the system on which files to enforce the constraints. When we started using git-svn, we added a second (server-side) check: that the magic string is not allowed in the commit message. That way, debugging commits can be made to the local git-svn-managed git repository but prevented from being "pushed" to Subversion. We have implemented something similar for git on the client side, using .gitattributes for its configuration. But this is not quite the same. When using pure git, there are cases when you want local commits that contain the forbidden string, but to prevent those commits from being pushed. For this, a server-side pre-update hook would be needed. This, in turn, has the technical problem that until recently .gitattributes were effectively unusable on the server. So we haven't yet implemented the analogous server-side hooks. An alternative would be to have some kind of "pre-push" hook which could carry out similar checks on the client. This would allow individuals to implement their own policy without requiring the central project to have a pre-commit hook. I don't believe that there is currently any such hook. > b) For history-rewriting operations, it is important to know which > commits are out in the wild and which are not. In a "push"-setup working > copy, git should be able to keep track of this. Any newly created commit > would be marked as "unpublished" and the mark would be removed when the > commit is pushed. Any history-rewriting would be prevented on published > commits. This would be convenient, too. Michael -- Michael Haggerty mhagger@xxxxxxxxxxxx http://softwareswirl.blogspot.com/ -- 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