1

I have a problem while trying to commit and sometimes a comment have slightly changed in some way (eg different number of spaces like // Text compared //Text). This is annoying and I would like to know if there is a way to make git ignore commented lines. Since git may be unaware of file type, language and so on, I guess I could restrict myself to ignore changes in lines containing //. My guess is that I could add some kind of rule for diff to ignore this, but there is another problem as well. How do I make git understand that these lines are supposed to be ignored in a comparison and still included in the repo?

EDIT As far as I know, this was done in svn. They had some smart implementation for this. My question is if there are something similar for git.

patrik
  • 4,506
  • 6
  • 24
  • 48
  • 1
    Git takes integrity of the files in the repository seriously. It tracks SHA hashes of all the files to make sure that nothing was accidentally or maliciously altered. This is a core design principle of Git. – Tadeusz A. Kadłubowski Aug 19 '15 at 10:24
  • 1
    Your request is self-contradicting. All VCSs keep track of the changes in files and they are designed to show the differences between versions. You want it to detect the differences and store them in the repository **and** ignore them in the same time. – axiac Aug 19 '15 at 10:24
  • 1
    @axiac it is not self contradicting. I do only want to commit files if the code have changed. In that case I update both all changed comments and the code. In case there is only a change in a comment it could be considered minor. Then it would be possible to manually do an `add`, but in case I do a commit, this file would be left untouched – patrik Aug 19 '15 at 10:30
  • @patrik: So your point is that you got used to `git commit -a` and that's a bad habit you're trying to break? – Tadeusz A. Kadłubowski Aug 19 '15 at 10:31
  • The workflow you suggest seems confusing to me. If you [`git add`](http://git-scm.com/docs/git-add) a file it means you want it to be included in the next commit. It's the first sentence in the description of [`git add`](http://git-scm.com/docs/git-add). – axiac Aug 19 '15 at 10:33
  • @TadeuszA.Kadłubowski, I normally commit changes, when my code is fine. I use some graphical tool here. However, sometimes the code within a file is changed (without conflicts), but there is a conflict in a comment. This is annoying, because if this comment says the same as before, but slightly change in format for different users, then there will be a conflict passed back and forth (if I solve it with git add). However, if this comment would change every now and then it would not matter. – patrik Aug 19 '15 at 10:36
  • @axiac yes exactly! If I have changed a comment which matters, then I can do a git add. If I know a comment is similar, but have a different format for another user, then I can update the whole file and ignore conflicts if I want to. And if no important code changes is done, then git can ignore the comment and not add it to the "changed file list in the gui". Just leave it. – patrik Aug 19 '15 at 10:39
  • You can probably achieve a part of what you want by using `git` [`hooks`](http://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) and a diff tool that can detect/ignore the changes in comments of the programming languages you use. – axiac Aug 19 '15 at 10:54

3 Answers3

2

I think that is not advisable. Consider two people are working on a comment simultaneously. Git should raise conflict. If you ignore comments, what do you expect git to do in that case? Besides, different programming languages have different syntax for comments. It would be little troublesome for git to identify comments.

You can definitely ignore space -w arguments to git. Example:-

git diff -w .
hspandher
  • 15,934
  • 2
  • 32
  • 45
  • That might have you end up in invalid comments or even worse doc string – hspandher Aug 19 '15 at 10:24
  • Ignore the conflict would not be so bad. Just keep the comment committed latest. My point is that the comment should somehow explain the code, so if the code is not changed on the same line, it should not matter. In case the code is changed, a commit should be done and then the comment would follow since it is the latest comment. – patrik Aug 19 '15 at 10:26
  • I meant if there are no comments (ever checked-in) then there couldn't be a conflict on them. Then I guess the question is why wouldn't OP just delete all their comments and never write any in their source code? So yes good +1 point it's not advisable. – Jeremy Thompson Aug 19 '15 at 10:27
  • 2
    As all human creations comments can be buggy too. Clarifying the purpose of the code, fixing spelling mistakes etc.etc. is a valid reason to change them. – Tadeusz A. Kadłubowski Aug 19 '15 at 10:28
  • @Tadeus that's why comments need to be fixed too as code does – hspandher Aug 19 '15 at 10:29
  • @JeremyThompson: 'Ignore the conflict' is a mythical '[DWIM]'(http://www.catb.org/jargon/html/D/DWIM.html) instruction. – Tadeusz A. Kadłubowski Aug 19 '15 at 10:30
1

Not specific to comments, but Git has an option to ignore space changes during the merge. See e.g. Merging without whitespace conflicts and http://git-scm.com/docs/git-merge.

Community
  • 1
  • 1
Matthieu Moy
  • 15,151
  • 5
  • 38
  • 65
  • Ok, I see, that seems to be solving one issue. I do also have a tab-space issue, but that is probably solved as well with this command. Unfortunately it will not work for minor changes in comments, but I think the spaces should be the most common issue. Thanks, I accept this. – patrik Aug 20 '15 at 05:23
0

I don't know if you can make git ignore the changes in the comments, this defeats the purpose of VCSs.

But you can use a smart comparison program that knows the lexical rules of several programming languages (or can be taught them) and is able to either ignore the changes in comments or show them as unimportant.

BeyondCompare is such a program.

axiac
  • 68,258
  • 9
  • 99
  • 134