Toshio Kuratomi <a.badger@xxxxxxxxx> 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. _______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
