On Mon, Sep 13, 2010 at 11:48 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Sun, Sep 12, 2010 at 11:03 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Having completed that comparison, I then moved on to trying to get rid of
>>> the discrepancies in the git conversion; particularly, trying to get rid
>>> of the "manufactured commits". I didn't have much success in that for the
>>> cases where the manufactured commit was caused by a back-branch file
>>> addition. [...] We still have "manufactured" commits either
>>> way, but they are just cosmetic so I guess we should live with them.
>
>> I'm not really following what the history looks like here. What are
>> the contents (git show) of the manufactured commit?
>
> A typical example is
>
> commit 4d2ac8075a93c685dbbe920f4bac23288dd7cf11
> Author: PostgreSQL Daemon <webmaster@postgresql.org>
> Date: Tue Nov 22 18:17:36 2005 +0000
>
> This commit was manufactured by cvs2svn to create branch 'REL7_4_STABLE'.
>
> Cherrypick from master 2005-11-22 18:17:34 UTC Bruce Momjian <bruce@momjian.us> 'Re-run pgindent, fixing a problem
wherecomment lines after a blank':
> src/port/unsetenv.c
>
> diff --git a/src/port/unsetenv.c b/src/port/unsetenv.c
> new file mode 100644
> index 0000000..bdfb3f6
> --- /dev/null
> +++ b/src/port/unsetenv.c
> @@ -0,0 +1,56 @@
> + [ entire contents of unsetenv.c here ]
>
> In the cases where I inserted a dead .0 revision, this is followed by
> something like
>
> commit a1bdd263ca8ff657365a97a560f6371f39295efc
> Author: Bruce Momjian <bruce@momjian.us>
> Date: Tue Nov 22 18:17:37 2005 +0000
>
> Mark branch as deleted.
If we have two commits one right after the other that cancel each
other out, we might be able to write them both out of the history
using git-filter-branch. But if Max or Michael can shed any light on
why it's happening, that might lead to a simpler solution.
>>> I also found numerous places where we'd been sloppy about placing tags.
>
>> I wonder if we should consider fixing some or all of these things on
>> the master CVS repository. I wouldn't be too eager to inject those
>> fake .0 commits for fear of breakage, but moving tags to where they
>> ought to have been all along seems like it might be a good thing to do
>> independent of git.
>
> Yeah, that's something I was wondering too. Applying these fixes to the
> master repository would also reduce the number of things we have to
> remember to do during the final conversion. OTOH, there's that risk of
> breaking something.
Hand-written patches that apply directly to the RCS files seem like
they'd be a risk for breakage, but I don't see why moving tags around
would be all that dangerous, especially in cases where you can do it
by running 'cvs' itself rather than 'rcs'. That should just be
routine stuff, no?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company