On Tue, 7 Feb 2012, Johan Herland wrote: > (we are pretty much in violent agreement, so I will only comment where > I find it necessary) So now comes the hard part: actually implementing (well, designing and implementing) prototypes for 'secret' trait and 'public' trait... > On Tue, Feb 7, 2012 at 15:31, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > > Also, when thinking about different scenarios of why one would like to > > mark commit as 'secret', we might want to be able to mark commit as > > secret / unpublishable with respect to _subset_ of remotes, so e.g. > > I am prevented from accidentally publishing commits marked as 'secret' > > to public repository, or to CI/QA repository, but I can push (perhaps > > with warning) to group repository, together with 'secret'-ness state > > of said commit... > > > > ... though it wouldn't be as much 'secret' as 'confidential' ;-) > > Another way to achieve this would be to have a config flag to control > whether Git checks for the 'secret' flag before pushing. This config > flag could be set at the system/user level (to enable/disable the > feature as a whole), at the repo level (to enable/disable it in a > given repo), at the remote level (to enable/disable it on a given > repo), and finally at the branch level (to enable-disable it for a > given branch (and its upstream)). Thus you could have a .git/config > that looked like this: > > [core] > refusePushSecret = true > > [remote "foo"] > refusePushSecret = false > url = ... > fetch = ... > > [branch "baz"] > remote = foo > merge = refs/heads/baz > refusePushSecret = true > > This config would: > > - refuse to push 'secret' commits from branch 'baz' > (branch.baz.refusePushSecret == true) > > - but allow to push other branches with 'secret' commits to remote > 'foo' (remote.foo.refusePushSecret == false) > > - but refuse to push 'secret' commits to other remotes > (core.refusePushSecret == true) > > (The order of precedence would be: branch config > remote config > > repo config > user config > system config > default when unset) You read my mind. > I am unsure whether the 'secret'-ness of a commit should follow across > the push, but if you do (assuming we store the 'secret' flag using > git-notes) this is simply a matter of synchronizing the > refs/notes/secret to the same remote. I think it should, so that 'secret' commit would not escape by accident via a group secret repository. What makes it hard (I think) is that we would prefer to transfer 'secret'-ness only for pushed commits. That might be problem for notes based implementation of 'secret' annotation and 'secret'-ness transfer... though I guess knowing that there exist 'secret' commit with given SHA1 which we do not have and should not have is not much breach of confidentiality. Still... -- Jakub Narebski Poland -- 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