git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: crlf with git-svn driving me nuts...

From
Nigel Magnay <nigel.magnay@gmail.com>
Date
Apr 16, 2008, 23:07 UTC
Message-ID
<320075ff0804161607p3f9e983ehb75aae4e0bfe8837@mail.gmail.com>
In-Reply-To
<20080416223739.GJ3133@dpotapov.dyndns.org>
Show 9 quoted lines
>  > The bit I really don't understand is why git thinks a file that has
>  > just been touched has chnaged when it hasn't,
>
>  Actually, it did change in the sense that if you try to commit this
>  file now into the repository, you will have a different file in Git!
>  So, it is more correct to say that Git did not notice this change until
>  you touch this file, because this change is indirect (autocrlf causes
>  a different interpretation of the file).
>

Okay - at the very least this behaviour is really, really confusing. And I think there's actually a bug (it should *always* report that the file is different), not magically after it's been touched.

But fixing that minor bug still leads to badness for the user. Doing (on a core.autocrlf=true machine) a checkout of any revision containing a file that is (currently) CRLF in the repository, and your WC is *immediately* dirty. However technically correct that is, it doesn't fit most people's user model of an SCM, because they haven't made any modification. And if 1 person makes a change along with their conversion, and the other 'just' does a CRLF->LF conversion, their revisions will conflict at merge time. Blech. And because the svn is mastered crlf (well, strictly speaking, it's ignorant of line endings) this is gonna happen a lot.

Can't git be taught that if the WC is byte-identical to the revision in the repository (regardless of autocrlf) then that ought not to be regarded as a change? Is there a way I can persuade the diff / merge mechanisms to normalise before they operate? (e.g if core.autocrlf does lf->crlf/crlf->lf, then an equivalent that does crlf->lf/crlf->lf before doing the merge )?

In a perfect world I'd be able to switch all files int he repo to LF, but that's not going to happen any time soon because of the majority of developers, still on svn, still on windows.

Previous: Avery PennarunNext: Dmitry Potapov
Message 10 of 19 in “crlf with git-svn driving me nuts...”
  1. Nigel MagnayApr 16, 2008
  2. Dmitry PotapovApr 16, 2008
  3. Avery PennarunApr 16, 2008
  4. Dmitry PotapovApr 16, 2008
  5. Nigel MagnayApr 16, 2008
  6. Martin LanghoffApr 16, 2008
  7. Avery PennarunApr 16, 2008
  8. Dmitry PotapovApr 16, 2008
  9. Avery PennarunApr 16, 2008
  10. Nigel MagnayApr 16, 2008
  11. Dmitry PotapovApr 17, 2008
  12. Avery PennarunApr 17, 2008
  13. Nigel MagnayApr 17, 2008
  14. Dmitry PotapovApr 17, 2008
  15. Nigel MagnayApr 17, 2008
  16. Dmitry PotapovApr 17, 2008
  17. Nigel MagnayApr 17, 2008
  18. Dmitry PotapovApr 17, 2008
  19. Steffen ProhaskaApr 17, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.