hosting git conversion of Fedora CVS tree on fedora infrastructure?

[Jim Meyering]

Toshio Kuratomi <a.badger at gmail.com> wrote:
> Jim Meyering wrote:
...
>> I consider the automated cvs-to-git mirroring to be the first step
>> in any conversion proposal:
>>
>> First, give people an idea of what they can expect in a git-based dVCS,
>> without requiring any change.  It lets people continue to use the tools
>> they're familiar with, and allows the better parts of a dVCS to begin
>> to show up the radar of those who haven't yet had time to explore them.
>
> I don't really buy this because it's a one-way transaction.  The
> people that need to be convinced that there's value in switching to
> git vs bzr vs hg vs svn also have commit rights to the main
> repository.  For a demo to reach this audience you need to get them
> the ability to work from this tree.  Which means they need to be able
> to checkout, checkin, tag, and request builds from it.

Hi Toshio,

[didn't we talk at a Mexican place after the fudcon in Boston?]

Using such a mirror need not be a one-way transaction.
Obviously, it'd be far less useful if there were such a limitation.

When I do serious work against an upstream CVS repository, I arrange to
mirror the CVS repo to git, and do all of my work in git, committing
changes on private git branches.  Then, I can easily rebase each of
those branches (sort of like cvs update), to synchronize with newer
upstream changes on the parent branch.[*]  When I want to commit to
cvs, it's easy to automate using git-cvsexportcommit.  While this MO is
not as comfortable as working in a git-only environment, it does help
give you a feel for what it'd be like, and *I* certainly appreciate it.
Of course, this can't help for tag/release-related operations, but it's
a good start for the rest.

Even with this slightly-contorted routine, I've appreciated using
git: for example, while using conventional diff, patch, and cvs,
it's easy to forget to "cvs add" a new file that was added by a patch.
It's also easy to forget to apply "chmod a+x..." to a script just added
by a patch.  But in git, that doesn't happen as much, because the tools
do more of the work for you.  And git-cvsexportcommit takes care of the
details of making sure everything in a git change set makes it back
into a cvs "commit".

Jim

[*] In case you haven't seen it yet, "git rebase --interactive" is very
useful, if you care about the "perfect patch" sort of process.
With it, there's no need for quilt/stgit/etc.