2

Is there a way to tell git to always ignore and discard local changes for a file that has been committed?

I've read about these options but neither appears to be what I want.

The scenario is that there's a particular file which needs to exist in order to compile, but some tool often does a pointless change to it during build (either stamping a version number or adding/removing insignificant whitespace). (It's not a "generated file" -- it does contain unique important content. It just also gets modified by a build tool. Unfortunately fixing the build process is not an option.)

As a result, it is always locally modified, and I always have to remember to revert it before committing or pulling or I'll get conflicts or create commits with those same pointless unrelated changes in it. (I always get the conflicts when checking out another branch, for example, partly because different instances of the pointless changes get baked in along with intentional changes in each branch.)

What I want is for git to always overwrite the local file with the upstream copy whenever it changes upstream (regardless of whether there are local changes or not), and then continue doing so without needing to toggle it again.

(I literally never make intentional changes to one such file. Another file I do very rarely make intentional changes to, but I'm ok with having to remember to unset a 'discard local' flag in that case and setting it again afterwards, and I don't care if I forget and the intentional changes are lost -- that's better than a checkout failing.)

Miral
  • 12,637
  • 4
  • 53
  • 93
  • A workaround will be add the entry of that file in .gitignore file that is present in the root project directory, ls -ltrh -a will show you that file (projects parent directory). in this way no matter what changes you are doing in ignored file (added in .gitignore) will always be ignored by git. You can have a look deeper in this link https://help.github.com/en/github/using-git/ignoring-files – Shankar Saran Singh Nov 22 '19 at 05:38
  • 1
    @ShankarSaranSingh That won't work here, because the file is already part of the remote repository. – Tim Biegeleisen Nov 22 '19 at 05:42
  • Additionally u can always do git checkout HEAD -- my-file.txt – Shankar Saran Singh Nov 22 '19 at 06:02

1 Answers1

0

You could create an alias in your .bash_profile which handles the various operations with an extra step to undo any changes which may have happened to the config file being discussed:

addcommpush() {
    git checkout -- path/to/your/config.file   # undo any changes to this file
    git add .
    git commit -m "$*"
    git push
}
alias acp=addcommpush

Run this as follows:

acp Your commit message goes here

Note that the alias contains a git checkout -- step, which would undo any changes made to the config file in your working directory.

Tim Biegeleisen
  • 502,043
  • 27
  • 286
  • 360
  • what about if there is a merge conflicts with other files in this way ? because you are doing git add . and git push after that – Shankar Saran Singh Nov 22 '19 at 05:51
  • Making a commit and pushing can't result in a merge conflict. Worse case scenario, some problem might block the commit, or maybe the push, but that is all. – Tim Biegeleisen Nov 22 '19 at 05:51
  • This isn't practical -- both because I use tools other than command-line git most of the time, and because there are lots of different actions which I want to be able to do that get tripped up by conflicting local changes. (Sometimes a commit, sometimes a checkout, sometimes a cherry-pick, sometimes a rebase, etc.) – Miral Nov 22 '19 at 05:52
  • @Miral Then you should fix your Git workflow. From what you described, the file in question in fact _is_ a build artifact, because the build process uses/alters it. If so, then maybe it really shouldn't be part of the Git repository. Except any solution you get here to not be completely ideal. – Tim Biegeleisen Nov 22 '19 at 05:53