Problem with case-insensitive file cleanup

Problem with case-insensitive file cleanup

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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).
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:

$ git pull
Already up-to-date.
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#
#	modified:   doc/functions/_Exit.texi
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git reset --hard HEAD
HEAD is now at 7464768... Merge branch 'master' of git://git.sv.gnu.org/gnulib
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#
#	modified:   doc/functions/_exit.texi
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git reset --hard HEAD
HEAD is now at 7464768... Merge branch 'master' of git://git.sv.gnu.org/gnulib
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#
#	modified:   doc/functions/_Exit.texi
#
no changes added to commit (use "git add" and/or "git commit -a")

What needs to happen to get rid of the _Exit.texi listing in the git
repository, so that case insensitive file systems can clone the gnulib.git
repository?

[1]http://lists.gnu.org/archive/html/bug-gnulib/2007-05/msg00012.html
[2]http://cvs.savannah.gnu.org/viewcvs/gnulib/doc/functions/Attic/_Exit.texi?rev=1.3&root=gnulib&view=log
[3]http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=tree;f=doc/functions;hb=a71ea03e4262db77dd90eaf35bad5fee6f79d15e

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGOdpl84KuGfSFAYARAhyEAJ9RFH9anyBa69uksVmG+0XetFJlvgCeNBsf
t1ppuGgwxq/kGr0G6qZGV6g=
=vS7d
-----END PGP SIGNATURE-----

Re: Problem with case-insensitive file cleanup

[Alex Riesen]

On 5/3/07, Eric Blake <ebb9@byu.net> 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).
> 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], ...

cvs-to-git conversion seem to be buggy in this respect

> What needs to happen to get rid of the _Exit.texi listing in the git
> repository, so that case insensitive file systems can clone the gnulib.git
> repository?

git update-index --force-remove _Exit.texi
git commit -m 'Really removed _Exit.texi'

Re: Problem with case-insensitive file cleanup

[Jim Meyering]

Eric Blake <ebb9@byu.net> 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.

Re: Problem with case-insensitive file cleanup

[James Youngman]

On 5/3/07, Jim Meyering <jim@meyering.net> wrote:

> > 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.

I have had related problems using git-cvsimport with the GNU findutils
source base and was eventually reduced to deleting the git repository
into which I was pushing the git-cvsimport result.    I had added a
directory to the CVS repository (findutils/build-aux) and it was not
showing up in the target git repository (i.e. the local directory I
was specifying as the argument of -C).

Fortunately since git is content-oriented (has foo-nature, whatever,
insert hand-wave here), once I have repeated the entire cvsimport
operation, pushing the regenerated result to the public git repository
only required an incremental amount of work (bandwdth).

But suffice to say, I do not believe that git-cvsimport is very
reliable.   People more familiar with git than I point the finger at
cvsps, but to be honest I don't know enough about either program to
arbitrate.

People also pointed me at alternatives to git-cvsimport but they all
had one or more of these drawbacks:
1. No support for incremental import
2. No support for tags
3. No support for branches

James.