Re: [RFD] Rewriting safety - warn before/when rewriting published history
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Feb 11, 2012, 13:45 UTC
- Message-ID
- <201202111445.33260.jnareb@gmail.com>
- In-Reply-To
- <CALKQrgdWOgG3y2HzM694zDykGJWa4QDetsEVXf0AGpf=FNFaVg@mail.gmail.com>
On Sat, 11 Feb 2012, Johan Herland wrote:
> On Fri, Feb 10, 2012 at 20:38, Jakub Narebski <jnareb@gmail.com> wrote: > > On Tue, 7 Feb 2012, Johan Herland wrote:
[...]
Show 19 quoted lines
> > > 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).
Or create per-remote custom notes ref, for example for 'foo' remote it would be 'refs/remotes/foo/notes/secret'... assuming that canonalization of remote-tracking refs goes in (refs/remotes/foo/{heads,tags,notes,replace})
This would be updated with 'secret'-ness state of comits being pushed before actual push, and secretness notes ref would be pushed together with actual push.
Show 5 quoted lines
> 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.
Hmmm... I thought that is 'public' feature that is more work, especially in full incarnation. But perhaps bare bones (no 'pre-push' or 'pre-rewrite' hooks, no traits info in "git log" output, per remote tracking of 'public' status only, no support for bundles or send-email, etc.) could be as easy or easier.
As to what is more important for git users... perhaps short survey would help here? I wonder if asking Mercurial users about their use of "phases" on their mailing would help us...
-- Jakub Narebski Poland