Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>There are multiple problems the can cause this behaviour:</p> <p><strong>Line ending normalization</strong></p> <p>I've had these kinds of problems too. It comes down to git automatically converting crlf to lf. This is typically caused by mixed line endings in a single file. The file gets normalized in the index, but when git then denormalizes it again to diff it against the file in the working tree, the result is different.</p> <p>But if you want to fix this, you should disable <em>core.autocrlf</em>, change all line endings to lf, and then enable it again. Or you can disable it altogether by doing:</p> <pre><code>git config --global core.autocrlf false </code></pre> <p>Instead of <em>core.autocrlf</em>, you can also consider using <a href="http://jk.gs/gitattributes.html" rel="noreferrer"><code>.gitattribute</code></a> files. This way, you can make sure everyone using the repo uses the same normalization rules, preventing mixed line endings getting into the repository.</p> <p>Also consider setting <em>core.safecrlf</em> to warn if you want git to warn you when a non-reversible normalization would be performed.</p> <p>The git <a href="http://jk.gs/git-config.html" rel="noreferrer">manpages</a> say this:</p> <blockquote> <p>CRLF conversion bears a slight chance of corrupting data. autocrlf=true will convert CRLF to LF during commit and LF to CRLF during checkout. A file that contains a mixture of LF and CRLF before the commit cannot be recreated by git. For text files this is the right thing to do: it corrects line endings such that we have only LF line endings in the repository. But for binary files that are accidentally classified as text the conversion can corrupt data.</p> </blockquote> <p><strong>Case-insensitive file systems</strong></p> <p>On case-insensitive filesystems, when the same filename with different casing is in the repository, git tries to checkout both, but only one ends up on the file system. When git tries to compare the second one, it would compare it to the wrong file.</p> <p>The solution would either be switching to a non-case insensitive filesystem, but this in most cases is not feasible or renaming and committing one of the files on another filesystem.</p>
    singulars
    1. This table or related slice is empty.
    1. POgit status shows modifications, git checkout -- <file> doesn't remove them
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USBartoszKP
    1. USIkke
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POgit status shows modifications, git checkout -- <file> doesn't remove them
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COOkay... so that did it... now git status shows no changes. I've read up on the autocrlf settings, and I just can't seem to get it right.
      singulars
      1. PO
      1. USrbellamy
    2. COGood catch! +1. Yet another argument for me setting that to false (http://stackoverflow.com/questions/1249932/git-1-6-4-beta-on-windows-msysgit-unix-or-dos-line-termination/1250133#1250133).
      singulars
      1. PO
      1. USVonC
    3. COWhat does this mean: "A file that contains a mixture of LF and CRLF before the commit cannot be recreated by git." Is this because git will always normalize line endings, based on the core.autocrlf setting?
      singulars
      1. PO
      1. USrbellamy
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload