On Sun, Aug 9, 2015 at 2:33 AM, Johannes Schlüter <johan...@schlueters.de> wrote:
> On Sun, 2015-08-09 at 00:48 +0200, Ferenc Kovacs wrote: > > Hannes, David, Johannes: what do you think? should we keep the current > > history (I diffed it and it seems to be the same content, only the > > commit metadata, author infor was changed) or should we force push the > > original history (of course for that we should first disable the email > > notifications in the gitolite config)? > > In general the consequence is that we can't trust the repo anymore. > There might be any change in the history. > > This is only the website, not the php-src repo correct? Then this isn't > as critical ... but I think we should still revert it. Anybody with an > old clone who isn't careful will eventually create a rather large merge > using the old history up to the point where the rewrite started. When > pushing that all commits will be sent, again. Also I assume the website > update scripts will now see a conflict and eventually stop updating the > website ;-) > yeah, it was only php-web. I've force pushed back the original version(albeit I was missing a single commit, but I managed to get that one from github even with the same sha1, so we have the same as we had before the accidental push). it shouldn't cause any problems with the website, mirrors pull via rsync, and on rsync we fetch via fetch + reset not via pull. > > We should probably restrict force pushing to all our "important" > branches (web/* etc.) as we do for php-src. > http://git.php.net/?p=karma.git;a=blob;f=hooks/pre-receive;h=9613854d53e0161e1081409a154fe91c1e130d17;hb=HEAD#l32 maybe we could protect the master branches in every repo from force pushes by default. > > Maybe this also is a good time to think about requiring signing commits. > For a start we might require at least the last commit during a push has > to be signed with gpg ... this won't prevent this case but still makes > the repos more trustworthy. Requiring all commits to be signed would be > nicer, and prevent rewriting history (unless the rewriter would sign all > commits with his key) but then we have to enforce this on github pulls > etc. ... > > we already have commit emails, and clients will also see if somebody force pushes (git client shows (forced update) when fetching) so I think it would be hard to sneak in something unnoticed, but I think that simply preventing force pushes for those handful who usually clean up when somebody screwes up should be enough. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
