Re: [RFD] Rewriting safety - warn before/when rewriting published history
- From
Steven Michalske <smichalske@gmail.com>
- Date
- Apr 7, 2012, 15:01 UTC
- Message-ID
- <6C977F5E-0C26-4165-AF2E-C032FA64F78B@gmail.com>
- In-Reply-To
- <CALKQrgdWOgG3y2HzM694zDykGJWa4QDetsEVXf0AGpf=FNFaVg@mail.gmail.com>
On Feb 11, 2012, at 9:10 PM, Johan Herland wrote:
Show 22 quoted lines
> On Fri, Feb 10, 2012 at 20:38, Jakub Narebski <jnareb@gmail.com> wrote: >> On Tue, 7 Feb 2012, Johan Herland wrote: >>> On Tue, Feb 7, 2012 at 15:31, Jakub Narebski <jnareb@gmail.com> 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).
Implementing these as bi-directional transfer of flag attributes might be a good working concept. This way we could implement the public flag and later add the secret flag, and later add the foo flag.
I say bidirectional because if Tom and mary are working on a group project. Mary publishes a commit to the public repo. When Tom pulls from Mary he should get the update for the flags that Mary published. If Mary pushes to Tom's repo it should update Tom's flags as well.
Show 8 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. > >
There are two kinds of pushes. Those to public facing repositories and those to a private working repository. Like a build bot repo. Pushes to that repo might not want to mark a commit as public.
Steve
Show 9 quoted lines
> ...Johan > > -- > Johan Herland, <johan@herland.net> > www.herland.net > -- > 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