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 ;-) We should probably restrict force pushing to all our "important" branches (web/* etc.) as we do for php-src. 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. ... johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
