{"thread":{"id":"7954","subject":"Problem with case-insensitive file cleanup","startedAt":"2007-05-03T12:49:41Z","lastAt":"2007-05-03T21:40:15Z","messageCount":4,"participants":["Eric Blake","Alex Riesen","Jim Meyering","James Youngman"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"40958","messageId":"4639DA65.3030401@byu.net","threadId":"7954","inReplyTo":null,"subject":"Problem with case-insensitive file cleanup","fromName":"Eric Blake","fromEmail":"ebb9@byu.net","sentAt":"2007-05-03T12:49:41Z","receivedAt":"2007-05-03T12:49:41Z","isPatch":false,"sender":{"key":"eblake@redhat.com","avatar":"https://avatars.githubusercontent.com/u/32933908?v=4"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nRight now, the gnulib repository is mastered in CVS but mirrored by git (I\nam still awaiting the day that Jim decides that his hooks are adequate\nenough that git can be the master and CVS provided by git-cvsserver).\nEarlier this week, I reported a problem when two case-insensitive files\nwere created, which is a no-no for checkouts on Mac HFS+ or Windows-based\nplatforms [1].  The problem was quickly corrected in CVS (note that\n_Exit.texi now lives in the attic [2]).  But somehow the git repository\nstill thinks that _Exit.texi belongs to the current tree [3], which leads\nto this confusing state on a case-insensitive clone:\n\n$ git pull\nAlready up-to-date.\n$ git status\n# On branch master\n# Changed but not updated:\n#   (use \"git add <file>...\" to update what will be committed)\n#\n#\tmodified:   doc/functions/_Exit.texi\n#\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n$ git reset --hard HEAD\nHEAD is now at 7464768... Merge branch 'master' of git://git.sv.gnu.org/gnulib\n$ git status\n# On branch master\n# Changed but not updated:\n#   (use \"git add <file>...\" to update what will be committed)\n#\n#\tmodified:   doc/functions/_exit.texi\n#\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n$ git reset --hard HEAD\nHEAD is now at 7464768... Merge branch 'master' of git://git.sv.gnu.org/gnulib\n$ git status\n# On branch master\n# Changed but not updated:\n#   (use \"git add <file>...\" to update what will be committed)\n#\n#\tmodified:   doc/functions/_Exit.texi\n#\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n\nWhat needs to happen to get rid of the _Exit.texi listing in the git\nrepository, so that case insensitive file systems can clone the gnulib.git\nrepository?\n\n[1]http://lists.gnu.org/archive/html/bug-gnulib/2007-05/msg00012.html\n[2]http://cvs.savannah.gnu.org/viewcvs/gnulib/doc/functions/Attic/_Exit.texi?rev=1.3&root=gnulib&view=log\n[3]http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=tree;f=doc/functions;hb=a71ea03e4262db77dd90eaf35bad5fee6f79d15e\n\n- --\nDon't work too hard, make some time for fun as well!\n\nEric Blake             ebb9@byu.net\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.5 (Cygwin)\nComment: Public key at home.comcast.net/~ericblake/eblake.gpg\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\n\niD8DBQFGOdpl84KuGfSFAYARAhyEAJ9RFH9anyBa69uksVmG+0XetFJlvgCeNBsf\nt1ppuGgwxq/kGr0G6qZGV6g=\n=vS7d\n-----END PGP SIGNATURE-----\n"},{"id":"40961","messageId":"81b0412b0705030632k5056ffc9sada117111598006d@mail.gmail.com","threadId":"7954","inReplyTo":"4639DA65.3030401@byu.net","subject":"Re: Problem with case-insensitive file cleanup","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-05-03T13:32:41Z","receivedAt":"2007-05-03T13:32:41Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 5/3/07, Eric Blake <ebb9@byu.net> wrote:\n> Right now, the gnulib repository is mastered in CVS but mirrored by git (I\n> am still awaiting the day that Jim decides that his hooks are adequate\n> enough that git can be the master and CVS provided by git-cvsserver).\n> Earlier this week, I reported a problem when two case-insensitive files\n> were created, which is a no-no for checkouts on Mac HFS+ or Windows-based\n> platforms [1].  The problem was quickly corrected in CVS (note that\n> _Exit.texi now lives in the attic [2]).  But somehow the git repository\n> still thinks that _Exit.texi belongs to the current tree [3], ...\n\ncvs-to-git conversion seem to be buggy in this respect\n\n> What needs to happen to get rid of the _Exit.texi listing in the git\n> repository, so that case insensitive file systems can clone the gnulib.git\n> repository?\n\ngit update-index --force-remove _Exit.texi\ngit commit -m 'Really removed _Exit.texi'\n"},{"id":"40962","messageId":"87odl2dnbk.fsf@rho.meyering.net","threadId":"7954","inReplyTo":"4639DA65.3030401@byu.net","subject":"Re: Problem with case-insensitive file cleanup","fromName":"Jim Meyering","fromEmail":"jim@meyering.net","sentAt":"2007-05-03T13:54:55Z","receivedAt":"2007-05-03T13:54:55Z","isPatch":false,"sender":{"key":"jim@meyering.net","avatar":"https://avatars.githubusercontent.com/u/710630?v=4"},"body":"Eric Blake <ebb9@byu.net> wrote:\n> Right now, the gnulib repository is mastered in CVS but mirrored by git (I\n> am still awaiting the day that Jim decides that his hooks are adequate\n> enough that git can be the master and CVS provided by git-cvsserver).\n\nMy plan, once we make the switch, is to set things up so that CVS\ndie-hards can use git-cvsserver for read-only gnulib operations.\n\nBTW, just yesterday there was a bug fix in git relating to git-cvsserver:\n\n    cvsserver: Handle re-added files correctly\n    http://git.kernel.org/?p=git/git.git;a=commitdiff;h=a7da9adb1ff\n\n> Earlier this week, I reported a problem when two case-insensitive files\n> were created, which is a no-no for checkouts on Mac HFS+ or Windows-based\n> platforms [1].  The problem was quickly corrected in CVS (note that\n> _Exit.texi now lives in the attic [2]).  But somehow the git repository\n> still thinks that _Exit.texi belongs to the current tree [3], which leads\n> to this confusing state on a case-insensitive clone:\n\nI've just removed that file manually and pushed the result.\nI suppose that happened because something went wrong with the\nautomated git-cvsimport run.\n\nThe current procedure is to rsync the CVS repository,\nuse that via git-cvsimport into an existing .git repository,\nand then to push the result to savannah.\n\nObviously, before we do the final CVS-to-GIT switch, I'll rerun\ngit-cvsimport from scratch, rather relying on the incrementally-built-up one.\n"},{"id":"40985","messageId":"c5df85930705031440n3b3025dalf566944da6069262@mail.gmail.com","threadId":"7954","inReplyTo":"87odl2dnbk.fsf@rho.meyering.net","subject":"Re: Problem with case-insensitive file cleanup","fromName":"James Youngman","fromEmail":"jay@gnu.org","sentAt":"2007-05-03T21:40:15Z","receivedAt":"2007-05-03T21:40:15Z","isPatch":false,"sender":{"key":"jay@gnu.org","avatar":"https://gravatar.com/avatar/8b346a7ca8e7b6f8ca5db01dd6cdb5a5d886013dfbf23105186fb8b036534e67?d=mp&s=160"},"body":"On 5/3/07, Jim Meyering <jim@meyering.net> wrote:\n\n> > Earlier this week, I reported a problem when two case-insensitive files\n> > were created, which is a no-no for checkouts on Mac HFS+ or Windows-based\n> > platforms [1].  The problem was quickly corrected in CVS (note that\n> > _Exit.texi now lives in the attic [2]).  But somehow the git repository\n> > still thinks that _Exit.texi belongs to the current tree [3], which leads\n> > to this confusing state on a case-insensitive clone:\n>\n> I've just removed that file manually and pushed the result.\n> I suppose that happened because something went wrong with the\n> automated git-cvsimport run.\n>\n> The current procedure is to rsync the CVS repository,\n> use that via git-cvsimport into an existing .git repository,\n> and then to push the result to savannah.\n>\n> Obviously, before we do the final CVS-to-GIT switch, I'll rerun\n> git-cvsimport from scratch, rather relying on the incrementally-built-up one.\n\nI have had related problems using git-cvsimport with the GNU findutils\nsource base and was eventually reduced to deleting the git repository\ninto which I was pushing the git-cvsimport result.    I had added a\ndirectory to the CVS repository (findutils/build-aux) and it was not\nshowing up in the target git repository (i.e. the local directory I\nwas specifying as the argument of -C).\n\nFortunately since git is content-oriented (has foo-nature, whatever,\ninsert hand-wave here), once I have repeated the entire cvsimport\noperation, pushing the regenerated result to the public git repository\nonly required an incremental amount of work (bandwdth).\n\nBut suffice to say, I do not believe that git-cvsimport is very\nreliable.   People more familiar with git than I point the finger at\ncvsps, but to be honest I don't know enough about either program to\narbitrate.\n\nPeople also pointed me at alternatives to git-cvsimport but they all\nhad one or more of these drawbacks:\n1. No support for incremental import\n2. No support for tags\n3. No support for branches\n\nJames.\n"}]}