Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>If the changes to your files are not actual changes, you should not submit them. This will clutter your version history and cause numerous problems.</p> <p>From your statement I’m not quite sure which is the case, but there are 2 possibilities:</p> <ol> <li><p>The file in question is a local storage file, the contents of which are not relevant for your actual sourcecode. In this case the file should be part of your .gitignore.</p></li> <li><p>This file is actually part of your source and will thus have relevant changes in the future. By setting up the merge settings like you are planning to do, you will cause trouble once this file actually changes. Because merges will then be destructive.</p> <p>In this case the solution is a little bit more complicated (apart from getting a fix for the crappy tool that changes stuff it doesn’t actually change …). What you are probably looking for is the <strong>assume unchanged</strong> functionality of git. You can access it with this command:</p> <pre><code>git update-index --assume-unchanged &lt;file&gt; </code></pre> <p><strong>git docu (<code>git help update-index</code>):</strong></p> <blockquote> <p>You can set "assume unchanged" bit to paths you have not changed to cause git not to do this check. Note that setting this bit on a path does not mean git will check the contents of the file to see if it has changed — it makes git to omit any checking and assume it has not changed. When you make changes to working tree files, you have to explicitly tell git about it by dropping "assume unchanged" bit, either before or after you modify them.</p> </blockquote></li> </ol>
 

Querying!

 
Guidance

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