Re: cvs2git reports a "sprout" from a nonexistent commit?

On Sun, Sep 12, 2010 at 8:41 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Sun, Sep 12, 2010 at 12:02 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> There are a couple of weird-looking commits way back near the beginning
>>> of the converted Postgres history:
>>>
>>> commit 91f2ac21a1e085dfe81aae110cee2246a803f600 refs/tags/Release_2_0_0
>>> Author: PostgreSQL Daemon <webmaster(at)postgresql(dot)org>
>>> Date:   Sat Aug 17 06:41:11 1996 +0000
>>>
>>>    This commit was manufactured by cvs2svn to create tag 'Release_2_0_0'.
>>>
>>>    Sprout from Release_1_0_3 1996-08-02 01:24:01 UTC PostgreSQL Daemon <webmaster(at)postgresql(dot)org> 'This commit was manufactured by cvs2svn to create branch 'Release_1_0_3'.'
>>>    Cherrypick from master 1996-08-17 06:41:10 UTC Marc G. Fournier <scrappy(at)hub(dot)org> 'changed missed err() change to err_out()':
>
>>> What is weird about them is that the referenced "sprout" commit doesn't
>>> exist.  Is this expected behavior?
>
>> What commit do you think doesn't exist?
>
> There is no commit with a log message like 'This commit was manufactured
> by cvs2svn to create branch 'Release_1_0_3'.'
>
> There is a another strange thing about these two commits: AFAICS they
> shouldn't exist at all.  Their content ought to be exactly the same as
> the immediately preceding mainline commits, so why didn't cvs2git just
> apply the branch tags to those mainline commits, instead of sprouting
> from a significantly earlier point on the mainline and then having to
> duplicate all the diffs from that time to this?

Oh, I get it now. That is pretty odd. I am not sure there is really
much point in keeping these ancient branches and tags. I'd argue for
losing all branches and tags that don't start with REL except perhaps
for PG95-1_01. Nobody's going to care about those anyway, and in the
very unlikely event that they do, they can refer back to CVS. (That
having been said, it would be interesting to know why it's
happening...)

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