{"thread":{"id":"21231","subject":"[msysgit? bug] crlf double-conversion on win32","startedAt":"2009-10-13T20:49:25Z","lastAt":"2009-10-14T20:46:46Z","messageCount":7,"participants":["Yann Dirson","Eric Raible","Johannes Schindelin","Laurent Boulard","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"124894","messageId":"38cfaa83fdf80dec3a3d81ed3e0de0e2.squirrel@intranet.linagora.com","threadId":"21231","inReplyTo":null,"subject":"[msysgit? bug] crlf double-conversion on win32","fromName":"Yann Dirson","fromEmail":"y.dirson@e-sidor.com","sentAt":"2009-10-13T20:49:25Z","receivedAt":"2009-10-13T20:49:25Z","isPatch":false,"sender":{"key":"y.dirson@e-sidor.com","avatar":null},"body":"With a msysgit 1.6.4 package, I got stuck after someone copied a CRLF file\nto a Linux box and committed it.\n\nIn that situation, the win32 client in autocrlf mode keeps telling that\nthe files are locally modified, even after eg \"git reset --hard\". Without\ntouching the crlf setting (which I believe should not ever be necessary),\nthis can be corrected by committing the faulty files after dos2unix'ing\nthem, and using \"git fetch && git reset --hard origin/master\" (\"git pull\n--rebase\" refuses to do the job since it believes there are local\nchanges).\n"},{"id":"124910","messageId":"loom.20091014T001602-378@post.gmane.org","threadId":"21231","inReplyTo":"38cfaa83fdf80dec3a3d81ed3e0de0e2.squirrel@intranet.linagora.com","subject":"Re: [msysgit? bug] crlf double-conversion on win32","fromName":"Eric Raible","fromEmail":"raible@gmail.com","sentAt":"2009-10-13T22:17:53Z","receivedAt":"2009-10-13T22:17:53Z","isPatch":false,"sender":{"key":"raible@gmail.com","avatar":null},"body":"Yann Dirson e-sidor.com> writes:\n\n> \n> With a msysgit 1.6.4 package, I got stuck after someone copied a CRLF file\n> to a Linux box and committed it.\n> \n> In that situation, the win32 client in autocrlf mode keeps telling that\n> the files are locally modified, even after eg \"git reset --hard\". Without\n> touching the crlf setting (which I believe should not ever be necessary),\n> this can be corrected by committing the faulty files after dos2unix'ing\n> them, and using \"git fetch && git reset --hard origin/master\" (\"git pull\n> --rebase\" refuses to do the job since it believes there are local\n> changes).\n\nSee http://thread.gmane.org/gmane.comp.version-control.git/122823/focus=122862\n\nIn which Junio suggests:\n$ rm .git/index\n$ git reset --hard\n\nin order to \"restore sanity to your work tree\"\n"},{"id":"124971","messageId":"alpine.DEB.1.00.0910141601580.4985@pacific.mpi-cbg.de","threadId":"21231","inReplyTo":"loom.20091014T001602-378@post.gmane.org","subject":"Re: [msysgit? bug] crlf double-conversion on win32","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-10-14T14:03:43Z","receivedAt":"2009-10-14T14:03:43Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 13 Oct 2009, Eric Raible wrote:\n\n> Yann Dirson e-sidor.com> writes:\n> \n> > \n> > With a msysgit 1.6.4 package, I got stuck after someone copied a CRLF file\n> > to a Linux box and committed it.\n> > \n> > In that situation, the win32 client in autocrlf mode keeps telling that\n> > the files are locally modified, even after eg \"git reset --hard\". Without\n> > touching the crlf setting (which I believe should not ever be necessary),\n> > this can be corrected by committing the faulty files after dos2unix'ing\n> > them, and using \"git fetch && git reset --hard origin/master\" (\"git pull\n> > --rebase\" refuses to do the job since it believes there are local\n> > changes).\n> \n> See http://thread.gmane.org/gmane.comp.version-control.git/122823/focus=122862\n> \n> In which Junio suggests:\n> $ rm .git/index\n> $ git reset --hard\n> \n> in order to \"restore sanity to your work tree\"\n\nOf course this is insane as a user interface. It is not even plumbing.\n\nSo I started some time ago to code a \"git checkout --fix-crlf\", but I \nam not really happy with the user interface. I think that Git should \nrealize itself that something went wrong with the line endings. If I say \n\"git reset --hard\", it is just a bug in Git when it insists afterwards \nthat the files are modified.\n\nCiao,\nDscho\n"},{"id":"124985","messageId":"cdea158b0910140859y3a914654nd293557eb44067e3@mail.gmail.com","threadId":"21231","inReplyTo":"alpine.DEB.1.00.0910141601580.4985@pacific.mpi-cbg.de","subject":"Re: [msysgit? bug] crlf double-conversion on win32","fromName":"Laurent Boulard","fromEmail":"laurent.boulard@gmail.com","sentAt":"2009-10-14T15:59:23Z","receivedAt":"2009-10-14T15:59:23Z","isPatch":false,"sender":{"key":"laurent.boulard@gmail.com","avatar":null},"body":"On Wed, Oct 14, 2009 at 16:03, Johannes Schindelin\n wrote:\n>> See http://thread.gmane.org/gmane.comp.version-control.git/122823/focus=122862\n>>\n>> In which Junio suggests:\n>> $ rm .git/index\n>> $ git reset --hard\n>>\n>> in order to \"restore sanity to your work tree\"\n>\n> Of course this is insane as a user interface.  It is not even plumbing.\n>\n> So I started some time ago to code a \"git checkout --fix-crlf\", but I\n> am not really happy with the user interface.  I think that Git should\n> realize itself that something went wrong with the line endings.  If I say\n> \"git reset --hard\", it is just a bug in Git when it insists afterwards\n> that the files are modified.\n\nI have to work on win32 at work and depending of projects, I have to\nplay with autocrlf/crlf config.\nSo I cannot do a git clone because it will inherit the global crlf\nconfiguration which is not want I want. My flow is often:\n\n$ git init ...\n$ git config core.autocrlf ...\n$ git remote add origin ...\n$ git fetch origin ...\n\nI stuffed those four lines behind a few git alias but I think having a\nconfig option for git init and git clone to set core.autocrlf in\nrepository would be a (small) improvement, isn't it ?\n\nLaurent.\n"},{"id":"124995","messageId":"279b37b20910141117s7980c249tab4565c93b389df3@mail.gmail.com","threadId":"21231","inReplyTo":"alpine.DEB.1.00.0910141601580.4985@pacific.mpi-cbg.de","subject":"Re: [msysgit? bug] crlf double-conversion on win32","fromName":"Eric Raible","fromEmail":"raible@gmail.com","sentAt":"2009-10-14T18:17:31Z","receivedAt":"2009-10-14T18:17:31Z","isPatch":false,"sender":{"key":"raible@gmail.com","avatar":null},"body":"On Wed, Oct 14, 2009 at 7:03 AM, Johannes Schindelin\n wrote:\n> Hi,\n>\n> On Tue, 13 Oct 2009, Eric Raible wrote:\n>\n>>\n>> See http://thread.gmane.org/gmane.comp.version-control.git/122823/focus=122862\n>>\n>> In which Junio suggests:\n>> $ rm .git/index\n>> $ git reset --hard\n>>\n>> in order to \"restore sanity to your work tree\"\n>\n> Of course this is insane as a user interface.  It is not even plumbing.\n>\n> So I started some time ago to code a \"git checkout --fix-crlf\", but I\n> am not really happy with the user interface.  I think that Git should\n> realize itself that something went wrong with the line endings.  If I say\n> \"git reset --hard\", it is just a bug in Git when it insists afterwards\n> that the files are modified.\n\nI fully agree that \"git reset --hard\" should actually, uh, do a hard reset,\nas should be clear in the my reply to Junio's suggestion. So I'm not\nadvocating \"rm .git/index\" as a good solution, but simply one that works.\n"},{"id":"125005","messageId":"7vfx9lersc.fsf@alter.siamese.dyndns.org","threadId":"21231","inReplyTo":"alpine.DEB.1.00.0910141601580.4985@pacific.mpi-cbg.de","subject":"Re: [msysgit? bug] crlf double-conversion on win32","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-14T18:47:47Z","receivedAt":"2009-10-14T18:47:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> So I started some time ago to code a \"git checkout --fix-crlf\", but I \n> am not really happy with the user interface. I think that Git should \n> realize itself that something went wrong with the line endings. If I say \n> \"git reset --hard\", it is just a bug in Git when it insists afterwards \n> that the files are modified.\n\nI tend to agree. \"git reset --hard-without-cached-stat-info\" that ignores\nthe cached stat information while it does the equivalent of the usual\n\"reset --hard\" may be a reasonably safe and usable alternative for\n\"checkout --fix-crlf\". When people see \"reset --hard...\", it will tell\nthem that this is about matching the index and the work tree with the\nnamed commit, as opposed to \"checkout\", so enhancing \"reset\" would make\nmore sense, I think.\n\nObviously, I am not seriously suggesting \"--hard-without-cached-stat-info\"\nas the name of this mode of operation, and you need to come up with a\nbetter one. But it is better than \"--crlf\", as it is not limited to the\ncrlf conversion that brings the inconsistency you will be resetting away.\nIt arises from any silent invalidation of the cached stat optimization\nafter you touch attributes and config.\n"},{"id":"125020","messageId":"279b37b20910141346p7915ae84qcb5b9c39e89f5d30@mail.gmail.com","threadId":"21231","inReplyTo":"7vfx9lersc.fsf@alter.siamese.dyndns.org","subject":"Re: [msysgit? bug] crlf double-conversion on win32","fromName":"Eric Raible","fromEmail":"raible@gmail.com","sentAt":"2009-10-14T20:46:46Z","receivedAt":"2009-10-14T20:46:46Z","isPatch":false,"sender":{"key":"raible@gmail.com","avatar":null},"body":"On Wed, Oct 14, 2009 at 11:47 AM, Junio C Hamano wrote:\n>\n> Obviously, I am not seriously suggesting \"--hard-without-cached-stat-info\"\n> as the name of this mode of operation, and you need to come up with a\n> better one.\n\nSince we already have --soft and --hard, how about --throbbing?\n"}]}