threads / discuss / 7954

Problem with case-insensitive file cleanup

Subject: Problem with case-insensitive file cleanup

## tl;dr

4 messages between May 3, 2007 and May 3, 2007.

replies: 3people: 4as markdown or json

Eric Blake· May 3, 2007, 12:49 UTC · lore

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

Alex Riesen· May 3, 2007, 13:32 UTC · re: Eric Blake · lore

Re: Problem with case-insensitive file cleanup

On 5/3/07, Eric Blake <ebb9@byu.net> wrote:

Show 8 quoted lines

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

Jim Meyering· May 3, 2007, 13:54 UTC · re: Eric Blake · lore

Re: Problem with case-insensitive file cleanup

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

Show 6 quoted lines

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

James Youngman· May 3, 2007, 21:40 UTC · re: Jim Meyering · lore

Re: Problem with case-insensitive file cleanup

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

Show 17 quoted lines

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