On Feb 7, 2012, at 11:09 PM, Johan Herland wrote: > (we are pretty much in violent agreement, so I will only comment where > I find it necessary) > > 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) > > 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 this would allow teamwork on selected remotes! Though after reading all the discussion on this thread I now feel that there are some different forms of secret. Stuff you want to only exist on your repository, hacks, junk and stuff. or Material that should not go to your public facing repository. or A commit containing a file that is not for public consumption, but something you want tracked in the same repo. This might be an incompatible concept; I cope with this by using a git submodule called internal in the code base, it works well. > > Have fun! :) > > ...Johan > > -- > Johan Herland, <johan@xxxxxxxxxxx> > www.herland.net > -- > 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 -- 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