Re: [RFD] Rewriting safety - warn before/when rewriting published history
- From
Philip Oakley <philipoakley@iee.org>
- Date
- Feb 10, 2012, 20:18 UTC
- Message-ID
- <1175EF538DAF4FE092F2CD307D0427C9@PhilipOakley>
- In-Reply-To
- <201202102038.55710.jnareb@gmail.com>
From: "Jakub Narebski" <jnareb@gmail.com> Sent: Friday, February 10, 2012 7:38 PM
Show 7 quoted lines
> 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...
It all sounds very sensible.
The one additional implemenation idea I'd like is to have, which is somewhat at a tangent to the secrecy issue, is having some record of what was pushed (made Public). For the sub-module case this is so that its super project can know if its submodules are public or not. A public super project that has 'secret' sub-modules is awkward to say the least.
That's my thought anyway...
Show 80 quoted lines
> >> On Tue, Feb 7, 2012 at 15:31, Jakub Narebski <jnareb@gmail.com> 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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2012.0.1913 / Virus Database: 2112/4801 - Release Date: 02/10/12 >