On Tue, Sep 7, 2010 at 5:47 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers