Problem with case-insensitive file cleanup
-----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 [email protected]
-----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-----
Quoted 8 lines · Eric Blake
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
Quoted 3 lines
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'
Quoted 3 lines · Eric Blake
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
Quoted 6 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.
Quoted 11 lines · Jim Meyering
Quoted 6 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.
Quoted 6 lines
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.