TortoiseGit flags changes when LabVIEW diff/compare finds no changes

[PeterB]

Hi folks,

I have been using TortoiseGit + Bitbucket for SCC for the past year and I have become rather frustrated with a recurring problem that I simply cannot find evidence of others experiencing.  For that reason I am convinced I am doing something wrong in my workflow but IDK what.

TortoiseGit flags changes to some files but when I use LabVIEW to do the diff/compare it finds no changes at all.  The file sizes of the falsely flagged files are unchanged, but the CRCs are changed. (inspected the binary difference below).  Before committing the changes I do a mass compile as NI suggested to me that might be the cause.  At one time that seemed to help, but not now.  Also I can confirm I have enabled the separation of source and compiled code in each vi and in the project.

WHY does this happen ?

Here are examples of file names and sizes that are unchanged (but falsely flagged as changed by TortoiseGit):

 Interpolate Magnitude (3 pts).vi       |  Bin 14665 -> 14665 bytes
 Order Magnitude from FFT [dB].vi   |  Bin 13741 -> 13741 bytes
 Peak Find 3 pts.vi                              |  Bin 21587 -> 21587 bytes
 Vector Sum [linear].vi                        |  Bin 12555 -> 12555 bytes

and one file changed which was truly flagged as a changed (note filesize diff)

Amendments.vi                                  |  Bin 54814 -> 54786 bytes

In one of the above files, below you can see the binary difference of 5 bytes occurs just prior to the first revision history comment, however no changes at all are found in all the history comments nor in the LabVIEW compare.  I spotted a similar kind of change (same location)  in a 2nd file I looked at.

Edited May 6, 2021 by PeterB
Added binary compare

[PeterB]

Perhaps I'll ask a higher level question.  For those of you who use source code control and perform comparisons between different commits, how often would LabVIEW falsely report differences exist ?

Here is what it looks like when I double click on vi having a claimed difference:

[JKSH]

On 5/6/2021 at 7:33 PM, PeterB said:

WHY does this happen ?

One cause is file metadata. For example, VIs store a "Revision Number" which can be different even if the block diagram, front panel, and icon are unchanged.

There are probably other causes too, but I don't know what those bytes represent.

 

2 hours ago, PeterB said:

For those of you who use source code control and perform comparisons between different commits, how often would LabVIEW falsely report differences exist ?

Pretty often, unfortunately. This is one thing that makes it hard to use source control with LabVIEW. I try to minimize these occurrences by making sure that I don't save a VI unless I've actually modified its contents.

P.S. Minor nitpick: It's not that "LabVIEW falsely report differences exist". Rather, LabVIEW causes differences to exist (in the byte sequences of a VI) even when the code is the same.

[PeterB]

Ah, thank you very much !    I am glad to know this reason.  It means it is unlikely to be something fundamentally wrong with the way I am using the tools, but instead that during development, code is being flagged as changed by LabVIEW (asterisk next to filename I presume), even though the programmer has not done any obvious change.  One thing I can think of might be the conversion from a different LabVIEW version.

That is one request I could add to the Ideas Exchange, for LabVIEW to either ignore differences that results in "0 differences" being reported, or to actually report it in a sensible way like "vi converted from different version of LabVIEW".

I agree now that it isn't a falsely reported difference (which I'd call a bug in IDE), just that LabVIEW doesn't want to tell you what the difference is !!

[joerghampel]

Another reason for git (not LabVIEW!) reporting changes where there don't seem to be any is file permission.

If your repository is on a filesystem where executable bits are unreliable (like FAT), git should be configured to ignore differences in file modes recorded in the index and the file mode on the filesystem if they differ only on executable bit:

git config --local core.filemode false

and/or

git config --global core.filemode false

 

And while we're at configuring git for Windows: Due to a Windows API limitation of file paths having 260 or fewer characters, Git checkouts fail on Windows with “Filename too long error: unable to create file” errors if a path is longer than the 260 characters. To resolve this issue, run the following command from GitBash or the Git CMD prompt:

git config --system core.longpaths true

(Taken from our public Dokuwiki)

[PeterB]

Thanks.  meaning changes in the file permission (chmod/file mode) could get flagged as changes by Git unless you configure Git as per your advice.