Re: Problem with case-insensitive file cleanup

[Jim Meyering]

Eric Blake <address@hidden> wrote:
> Right now, the gnulib repository is mastered in CVS but mirrored by git (I
> am still awaiting the day that Jim decides that his hooks are adequate
> enough that git can be the master and CVS provided by git-cvsserver).

My plan, once we make the switch, is to set things up so that CVS
die-hards can use git-cvsserver for read-only gnulib operations.

BTW, just yesterday there was a bug fix in git relating to git-cvsserver:

    cvsserver: Handle re-added files correctly
    http://git.kernel.org/?p=git/git.git;a=commitdiff;h=a7da9adb1ff

> Earlier this week, I reported a problem when two case-insensitive files
> were created, which is a no-no for checkouts on Mac HFS+ or Windows-based
> platforms [1].  The problem was quickly corrected in CVS (note that
> _Exit.texi now lives in the attic [2]).  But somehow the git repository
> still thinks that _Exit.texi belongs to the current tree [3], which leads
> to this confusing state on a case-insensitive clone:

I've just removed that file manually and pushed the result.
I suppose that happened because something went wrong with the
automated git-cvsimport run.

The current procedure is to rsync the CVS repository,
use that via git-cvsimport into an existing .git repository,
and then to push the result to savannah.

Obviously, before we do the final CVS-to-GIT switch, I'll rerun
git-cvsimport from scratch, rather relying on the incrementally-built-up one.