Re: Policy decisions and cosmetic issues remaining for the git conversion

On Mon, Sep 13, 2010 at 1:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Mon, Sep 13, 2010 at 12:50 PM, Alvaro Herrera
>> <alvherre(at)commandprompt(dot)com> wrote:
>>> +1 on both -- fixing the broken tags, and creating the missing tags,
>>> particularly since you already seem to have found out the necessary
>>> dates for the missing tags.
>
>> +1 from me, too.  I don't agree with statements upthread that this
>> will be "easier" to do in git.  I think we should fix the CVS history.
>>  The git conversion is a one-time event.  Once it's done, history is
>> set in stone.  We don't want to set the wrong thing in stone.
>
> Well, the other side of that argument is that changing these things in
> the CVS repository will be overwriting the available evidence, in case
> any questions come up later.  On the git side, applying the tag to the
> appropriate commit is an easy --- and easily changeable --- thing, isn't
> it?

You can apply the tag to any commit that you want easily enough, but
you can't change even the least detail of the commit contents. So if
it turns out that there's no commit that exactly matches the desired
tag contents, then things get sticky. That's why we need to make sure
that the reconstructed series of commits exactly matches what really
happened as closely as possible the first time through. If it
doesn't, we're pretty hosed.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company