On Tue, Sep 7, 2010 at 5:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> BTW, why is this commit shown as being a predecessor of refs/tags/REL8_4_4
> and not refs/tags/REL8_4_3? That's nothing to do with it.po, perhaps,
> but it sure looks wrong. (Magnus, did you check against the 8.4.3 tarball?)
I think this is another result of the same basic problem. Since
cvs2git thinks it.po was added to REL8_4_STABLE on 2010-02-28 rather
than 2010-05-13,the REL8_4_STABLE version that existed on to
2010-03-12, when 8.4.3 was tagged, includes that file. But cvs2git
also knows that 8.4.3 does NOT include that file, so it picks the
commit on the 8.4.3 branch that most closely matches the contents of
the tag (namely, Marc's "tag 8.4.3" commit) and then shoves a
manufactured commit on top of that to make the contents of the 8.4.3
tag match what actually got tagged. But that manufactured commit is
only there to make the tag contents match; it's not actually part of
the branch. If the conversion correctly made it.po get added on
2010-05-13 rather than 2010-02-28 then Marc's "tag 8.4.3" commit would
match the tag contents exactly and no manufactured commit would be
created.
The effect of all of this is that if someone checks out a git commit
between 2010-02-28 and 2010-05-13, it.po will be there, even though
file didn't exist on that CVS branch at that time. Max's contention
seems to be that this is a CVS problem rather than a cvs2git problem.
Perhaps we can do something like cvs update -r REL8_4_STABLE -d
SOME_INTERMEDIATE_DATE and see whether that file is there or not.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company