Peter Eisentraut wrote:
> On Thursday 25 December 2008 01:47:49 Jeff Davis wrote:
>> On Mon, 2008-12-22 at 19:40 +0200, Heikki Linnakangas wrote:
>>> I hacked cvsps a little bit, to move the first commit on the branch
>>> right after the correct branch point, before writing the output. This is
>>> a hack, but seems to work at least for the PG repository.
>>>
>>> I'm not sure if we want to run a hacked version of cvsps. But then
>>> again, the current conversion isn't exactly error-free either, and we're
>>> missing tags...
>> Do you think this hack (or at least a problem report) would be accepted
>> upstream by the git community?
>
> cvsps is not part of git. It's a separate package, that has been unmaintained
> for a great while, and there are already some forks out there. Which is part
> of the problem, overall ...
Yep. The git people are certainly aware of the problem, there's plenty
of discussion about it on the mailing lists. I don't know if this
particular hack has been proposed before, I don't think I saw anything
identical in the mailing lists, though people have posted cvsps hacks to
fix it before.
Another problem with git-cvsimport is that only branches that have had
any commits to them show up in the GIT repository. This hack won't fix
that. If cvsps injected a dummy "branch commit" at the right place,
instead of the reordering that my hack does, that might be fixed too.
What are we going to do about this? I have the feeling that I have the
greatest itch to get the repository fixed. I propose that I will try
that dummy "branch commit" hack in cvsps, and if it works out, create a
new GIT repository using that. That would replace the current
repository, which means that people working against that repository will
need to use "git-fetch --force" to update their clones, and rebase their
own branches. It would also be good to contribute the hack into upstream
cvsps (whatever fork is considered upstream).
I'd like to move to git-cvsimport because:
- it converts tags
- I'm more familiar with it than fromcvs/togit.
However, if anyone else is willing to pick up the ball, I'll just shut
up and be happy that something gets done.
One option is to just leave it as it is, but it's not nice that the
history is repeated multiple times. The repository is big enough without
that..
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
