0

I have a list of files that git says are changed because there is a change in a comment. How can I configure Git to ignore files (not show as modified), when only comment is changed. For example The original file contains;

def foo():
    # Return
    return bar

Now the file is changed to (Comment is changed to # Return bar)

def foo():
    # Return bar
    return bar

Now when I run git status, the above file is shows as modified. I want this change to be ignored. How can I configure Git to ignore these files.

EDIT: The date and time are written as comments in my .py file. When only these comments change I do not want to commit this file with my other files (where the change needs to be committed).

  • 3
    Possible duplicate of [How to tell git to ignore individual lines, i.e. gitignore for specific lines of code](https://stackoverflow.com/questions/16244969/how-to-tell-git-to-ignore-individual-lines-i-e-gitignore-for-specific-lines-of) – gold_cy Mar 21 '19 at 14:20
  • 3
    but to add on, this kind of defeats the purpose of Git – gold_cy Mar 21 '19 at 14:21
  • Possible duplicate of [How to make git diff ignore comments](https://stackoverflow.com/questions/16527215/how-to-make-git-diff-ignore-comments) – Liam Mar 21 '19 at 14:23
  • 2
    @aws_apprentice is spot on. I'm curious what specific problem you're trying to solve with this behavior. Barring the ugly hack in the linked question (which I don't recommend), it's really all or nothing (gitignore) when it comes to files. Because of the design of git, things could get really out of hand if many people can make edits to a file that was partially checked in. What would happen if you and a coworker had different comments and both pushed? How would git remedy this? – Bailey Parker Mar 21 '19 at 14:24
  • In My python files, the date and time are automatically written as comments. I want to ignore a file where only date and time comment is changed. –  Mar 21 '19 at 14:27
  • .gitignore is the file should be updated, but please check the existing post first. – Chuan Mar 21 '19 at 14:28
  • 1
    @daanav If you implement this, you'll end up with desynchronized content everywhere, it will be hell. – Romain Valeri Mar 21 '19 at 14:31
  • 1
    I'd recommend stopping whatever is writing the date/time from doing that rather than changing the way git works. – Holloway Mar 21 '19 at 14:33
  • I need the date and time as it is a requirement for the company. I cannot change this requirement. –  Mar 21 '19 at 14:39
  • You will have to create a custom smudge and and clean filters that manages this, but it's not going to be easy to do. Basically, someone at your company doesn't understand the tools you're using so they have made a bad policy. The only correct and sane and *easy* fix is to change the policy. Also, why do you need to have the date and time in the file **if you're not committing that change to git?** Can't you simply say "trust me, the local file is correct"? – Lasse V. Karlsen Mar 22 '19 at 07:50
  • The question is, if you do something else to the file, and thus commit it, do you want the changed comments to be a part of this, or do you want them to be reset to whatever the file had on the last commit in the repository? – Lasse V. Karlsen Mar 22 '19 at 07:52
  • Also, if this file is *generated*, you might even consider not committing the file to the repository at all. – Lasse V. Karlsen Mar 22 '19 at 07:53

1 Answers1

1

As many of the commentors have said, you are fixing the wrong problem.

There is not really a way to do this in git, as it uses the entire file contents to create a SHA. This SHA is compared to the previous SHA. If the SHA changes, this means the contents of the file has changed.

I can't think of a way of doing this, which would leave the file contents consistent across all versions. If the comments (date/time) are not important enough to be stored in git, then don't add them there in the first place. If it is your editor or IDE that is doing it, then either stop it doing it or change the editor/IDE

Your comment regarding this being a company requirement was hidden initially for me. As this is a requirement for the company, then you need to get them to change policy (This is duplicating information stored in the git metadata for the commit) or accept it and carry on.

git blame will give you better information on who is making changes and when, as it identifies who has made each change to the file, and when.

Edit: As mentioned below by MarkAdelsberger below, git status does use the file's stat information, but as stated, this still leads to the same answer. Here are a technical doc and a blog post which explain some of the details.

Xetius
  • 44,755
  • 24
  • 88
  • 123
  • 1
    This is mostly good information, but note that the question specifically asks about `git status` - and the hash comparison is not relevant to which files `git status` report as modified. Rather that is based on the file's stat info. Now, that still leads to the same answer: you can't (and even if you could, you'd run into the hash issue as soon as you made a commit anyway) – Mark Adelsberger Mar 21 '19 at 15:23
  • 1
    Thank you @MarkAdelsberger, I was unaware that it did this. I have always believed that it was based off of the hash as you can manipulate the file systems date/time for mtime. Thanks for the clarification. I will read the git source in future so I don't say stupid things – Xetius Mar 22 '19 at 07:29
  • I wouldn't call it stupid. It is a fairly common misconception because the hash comparison is highly touted ; but the problem is, until a file is cached its hash isn't calculated (and hashing everything in the work tree at once would be too slow). Which does point out something I should amend - when I said `status` doesn't use hashes, that's half true - the half of the time when it's showing unstaged changes - but staged changes are of course calculated using the object hashes. – Mark Adelsberger Mar 22 '19 at 13:29