On Fri, Feb 10, 2012 at 20:38, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > On Tue, 7 Feb 2012, Johan Herland wrote: >> On Tue, Feb 7, 2012 at 15:31, Jakub Narebski <jnareb@xxxxxxxxx> wrote: >> 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... If you don't want to transfer all of refs/notes/secret, you would probably have to extend the git protocol with a per-commit 'secret' flag (which would then be applied to the receiving repo's refs/notes/secret). Still, this is all specific to the 'secret' feature, which IMHO is much less important then the 'public' feature. Implementing the barebones 'public' feature (i.e. refuse rewrite of commits reachable from upstream) is much less work, and would be enough for 90% of git users, I believe. ...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