Re: Problem in GIT mirror (was Re: pgsql: Fix all the server-side SIGQUIT handlers ...)

Magnus Hagander wrote:
> Magnus Hagander wrote:
>> Alvaro Herrera wrote:
>>> Alvaro Herrera wrote:
>>>> Tom Lane wrote:
>>>>> Log Message:
>>>>> -----------
>>>>> Fix all the server-side SIGQUIT handlers (grumble ... why so many identical
>>>>> copies?) to ensure they really don't run proc_exit/shmem_exit callbacks,
>>>>> as was intended. I broke this behavior recently by installing atexit
>>>>> callbacks without thinking about the one case where we truly don't want
>>>>> to run those callback functions. Noted in an example from Dave Page.
>>>> Something seems wrong on the GIT mirror. This patch appears as
>>>> http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=e5a8ea96adf14b9d822aff82d8f4ebf41d3a8e95
>>>> however, it only shows the diff for xlog.c, not the other files that
>>>> were touched by this commit.
>>> So I foolishly assumed that it would fix itself when the next sync
>>> occured, but several hours have passed and the problem still exists.
>>>
>> I tried to figure something out about this, but I have no clue.
>>
>> The rsync:ed copy of the cvs repository that the conversion runs at has
>> all the changes.
>>
>> The git repository has only the xlog.c one (checked in the server repo
>> as well just to be sure it wasn't anything in the gitweb install or
>> anything)
>>
>> The ruby magic ("fromcvs") that does the importing says nothing - it
>> runs without any complaints and says there is nothing to do.
>>
>>
>> Any ideas at all where to look?
>>
>> I wonder if the many identical copies somehow broke the import script or
>> something...
>
>
> Ok, a bit further.
>
> I tried restoring a backup and re-running the conversion script. Then it
> works.

I've done this now for the production repositories. I tried on my git
clone, and it actually works to do "git pull". I get two commits for the
broken one, but the code that is in the files in my master branch is the
correct one.

It may be that this fails copmletely if there is a merge failure or
something. In that case, I'm told you can do a git reset --hard to get
back to life. It's painful, but it's something.

We figured it was just as well to bite the bullet now, because the
longer we wait the more issues people would have with it.

I'd appreciated if people can run some tests and make sure there aren't
any issues in it now - for the moment, I still have the old corrupt
repository around if we need it :-)

//Magnus