Re: git: uh-oh - Mailing list pgsql-hackers

From Tom Lane
Subject Re: git: uh-oh
Date
Msg-id 24200.1282329002@sss.pgh.pa.us
Whole thread Raw
In response to git: uh-oh  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: git: uh-oh
List pgsql-hackers
Max Bowsher <maxb@f2s.com> writes:
> My guess at this point is that there may be a (very old?) version of cvs
> which, when adding a file to a branch, actually misrecorded the file as
> having existed on the branch from the moment it was first added to trunk
> - this would explain this anomaly.

I have no idea what version of CVS is running on our master server.
I have noticed that it sometimes generates its own synthetic commit
messages for cases related to this, for example these events on HEAD:

2010-05-13 12:40  adunstan
* src/pl/plperl/sql/plperlu_plperl.sql: file plperlu_plperl.sql wasinitially added on branch REL8_4_STABLE.

2010-05-13 12:40  adunstan
* src/pl/plperl/expected/plperlu_plperl.out: fileplperlu_plperl.out was initially added on branch REL8_4_STABLE.

I don't see one of these for plperl_opmask.pl in particular, so there
may be more than one anomaly involved.

However, the bottom line here is that we don't want the history that
cvs2git is preparing for these events, because it doesn't correspond to
what we did.  Whether this is the "most faithful" representation of the
CVS history is academic; it simply is not reality.  What we would like
is for the history to look like the file got added to the branch as of
the first commit that touched it on that branch.  That is reality, as
it appears from our neck of the woods anyway.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: [Glue] Deadlock bug
Next
From: David Fetter
Date:
Subject: Re: Version Numbering