Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Not easily through <a href="http://git-scm.com/docs/gitattributes" rel="nofollow noreferrer"><code>gitattributes</code></a>, since <strong>negative pattern</strong> are forbidden.</p> <p>There is actually a patch being proposed this days (March 2013) to <a href="http://git.661346.n2.nabble.com/PATCH-Make-pattern-in-gitattributes-non-fatal-td7578826.html" rel="nofollow noreferrer">Make <code>!pattern</code> in <code>.gitattributes</code> non-fatal</a>.</p> <p>So you need to put a global rule like <code>*.txt</code> only in <code>.gitattributes</code> files present in sub-directories where you <em>known</em> you won't need CRLF.</p> <p>And reserve more fine-grained <code>text</code> rules in <code>.gitattributes</code> present in directories with mixed content.</p> <hr> <p><a href="https://stackoverflow.com/users/105137/kostmo">kostmo</a> mentions <a href="https://stackoverflow.com/questions/17161535/is-it-possible-to-commit-a-file-that-defies-the-line-ending-behavior-specified-b/17162483#comment31201008_17162483">in the comments</a> the <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=421364" rel="nofollow noreferrer">EGit bug 421364</a>:</p> <blockquote> <p>Until this is implemented, I recommend this setup:</p> <ol> <li>For each Eclipse project, go to <code>Properties &gt; Resource</code> and change "<code>New text file line delimiter</code>" to <code>Other: Unix</code>. Commit the resulting <code>.settings/org.eclipse.core.runtime.prefs</code> files.</li> <li>Don't configure any <code>.gitattributes</code> or "<code>core.autocrlf</code>" for Git.<br> This means that files will have the same line endings in the working directory as in the repository. Git and EGit will not convert any file contents.</li> </ol> <p>With 1., all new files that are created in Eclipse will have correct (<code>LF</code>) line endings, even when created by a user on Windows.</p> <p>For files that are already in your repository with <code>CRLF</code>, you can fix them and commit the result. I recommend using <code>dos2unix</code> or <code>fromdos</code> on the command line.</p> </blockquote> <p>Note: that issue (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=421364" rel="nofollow noreferrer">bug 421364</a>) has just now (March 25th, 2014) been requalified as duplicate of <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=342372" rel="nofollow noreferrer">bug 342372</a> by <a href="http://www.vogella.com/people/larsvogel.html" rel="nofollow noreferrer">Lars Vogel</a>.</p> <p>So, the support of <code>.gitattributes</code> by JGit is "assigned", but its implementation is <del>still in progress</del>.</p> <p>The implementation is being reviewed (January 2015):</p> <ul> <li>"<a href="https://git.eclipse.org/r/#/c/1614/" rel="nofollow noreferrer">review 1614</a>" <strong>Add basic support for <code>.gitattributes</code></strong></li> </ul> <blockquote> <p>Core classes to parse and process <code>.gitattributes</code> files including support for reading attributes in WorkingTreeIterator and the dirCacheIterator.</p> </blockquote> <ul> <li>"<a href="https://git.eclipse.org/r/#/c/35377/" rel="nofollow noreferrer">review 35377</a>" <strong>Adds the git attributes computation on the treewalk</strong></li> </ul> <blockquote> <p>Adds the <code>getAttributes</code> feature to the tree walk.<br> The computation of attributes needs to be done by the <code>TreeWalk</code> since it needs both a <code>WorkingTreeIterator</code> and a <code>DirCacheIterator</code>.</p> </blockquote> <hr> <p>Update August 2018: the bug mentioned above (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=342372" rel="nofollow noreferrer">bug 342372</a>) depends on <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=537410" rel="nofollow noreferrer">JGit bug 537410</a>, which just got resolved.<br> "<strong>JGit rebase and stash dont preserve line ending</strong>s"</p> <blockquote> <p>The problem is that the <code>ResolveMerger</code> during <code>processEntry()</code> does not remember the <code>CheckoutMetadata</code> (in which JGit stores filters and eol-attributes) for the files and then checks them out in <code>checkout()</code> ignoring any attributes or filters.</p> <p><code>ResolveMerger.cleanUp()</code> has the same problem.</p> </blockquote> <p><a href="http://git.eclipse.org/c/jgit/jgit.git/commit/?id=4027c5c9ffc9fb99b2c06b9a7ecdeb18838e8218" rel="nofollow noreferrer">JGit commit 4027c5c</a> (from <a href="https://git.eclipse.org/r/#/c/127290/" rel="nofollow noreferrer">review 127290</a>) should fix that.<br> THanks to <strong>Thomas Wolf</strong> an <a href="https://dev.eclipse.org/mhonarc/lists/jgit-dev/msg03414.html" rel="nofollow noreferrer">active contributor to JGit</a>.</p> <p>That gives hope for EGit:</p> <blockquote> <p>EGit in general leaves all this eol handling in staging/merging/checkout to JGit.<br> The only places where EGit has to care about it is in the compare framework when it has to read index entries itself, and there it already properly handles <code>CheckoutMetadata</code>.</p> </blockquote>
    singulars
    1. This table or related slice is empty.
    1. POIs it possible to commit a file that defies the line ending behavior specified by .gitattributes?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USVonC
    1. USVonC
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POIs it possible to commit a file that defies the line ending behavior specified by .gitattributes?
      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
    1. COOK, so to paraphrase my question, is the above `.gitattributes` file an *absolutely foolproof* way to prevent new CRLF lines from being committed to `*.txt` files in the directory that contains the `.gitattributes` file? I want to convince my colleagues that the `.gitattributes` file is sufficient, and that further measures to exclude CRLFs (e.g. a server-side hook) are unnecessary.
      singulars
      1. PO
      1. USkostmo
    2. CO@kostmo yes, as long as you keep config `core.autocrlf` to `false` (http://stackoverflow.com/a/2016763/6309): you can define `eol` rules in the `.gitattributes`: see http://stackoverflow.com/a/12702862/6309
      singulars
      1. PO
      1. USVonC
    3. COAre you saying that if `core.autocrlf` was `true`, a user could produce a commit that defies the `.gitattributes` setting?
      singulars
      1. PO
      1. USkostmo
 

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