Mark and protect local commits?

Mark and protect local commits?

[norbert.nemec]

Hi there,

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.

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.


Has anyone else thought along these lines?

Greetings,
Norbert

Re: Mark and protect local commits?

[Michael Haggerty]

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@alum.mit.edu
http://softwareswirl.blogspot.com/