Re: gitweb is no longer a real-time view - Mailing list pgsql-www

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Andres Freund wrote:
>> I think the most realistic way to resolve this is to push the current
>> anongit state to master and cherry-pick
>> bc61878682051678ade5f59da7bfd90ab72ce13b ontop it. That way only
>> committers need to deal with rebasing their branches and not everyone
>> else.

> I agree this seems the sanest course of action, but I think it would be
> better to install defenses in the master repo so that forced pushes are
> no longer allowed *before* rebasing gitmaster; otherwise some other
> committer could clobber things again if they don't force-pull their
> trees.

Agreed.  I'm astonished that we had this configured this way in the
first place.

FWIW, I noticed something about a "forced update" when I did a git pull
after Kevin's commits.  I failed to pay enough attention though.  Now
that I look, the xml fix is not in my local history either, and I don't
know what bc61878682051678ade5f59da7bfd90ab72ce13b is because none of
the recent commits have that hash according to my repo:

$ git status
# On branch master
nothing to commit (working directory clean)
$ git log
commit d63977eea3ab18fdec05e370b633d10b9fd20179
Author: Kevin Grittner <kgrittn@postgresql.org>
Date:   Sun Mar 3 18:38:44 2013 -0600
   Remove accidentally-committed .orig file.

commit 3bf3ab8c563699138be02f9dc305b7b77a724307
Author: Kevin Grittner <kgrittn@postgresql.org>
Date:   Sun Mar 3 18:23:31 2013 -0600
   Add a materialized view relations.      A materialized view has a rule just like a view and a heap and   other
physicalproperties like a table.  The rule is only used to   populate the table, references in queries refer to the
materializeddata.      This is a minimal implementation, but should still be useful in   many cases.  Currently data is
onlypopulated "on demand" by the   CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements.   It is expected
thatfuture releases will add incremental updates   with various timings, and that a more refined concept of defining
whatis "fresh" data will be developed.  At some point it may even   be possible to have queries use a materialized in
placeof   references to underlying tables, but that requires the other   above-mentioned features to be working first.
   Much of the documentation work by Robert Haas.   Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja
Securityreview by KaiGai Kohei, with a decision on how best to   implement sepgsql still pending.
 

commit b15a6da29217b14f02895af1d9271e84415a91ae
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Sun Mar 3 19:05:47 2013 -0500
   Get rid of any toast table when converting a table to a view.      Also make sure other fields of the view's
pg_classentry are appropriate   for a view; it shouldn't have relfrozenxid set for instance.      This ancient omission
isn'tbelieved to have any serious consequences in   versions 8.4-9.2, so no backpatch.  But let's fix it before it does
bite  us in some serious way.  It's just luck that the case doesn't cause   problems for autovacuum.  (It did cause
problemsin 8.3, but that's out   of support.)      Andres Freund
 

commit 2b78d101d1d6b1d8533a7b7aeff4d82b10a915f8
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Sun Mar 3 17:39:58 2013 -0500
   Fix SQL function execution to be safe with long-lived FmgrInfos.           regards, tom lane