How do I set up Git to ignore trivial changes (for example, file timestamp) in a file?

Asked

Viewed 162 times

3

The problem I’m facing is this::

The C application has an option where the build date of the application is displayed. To prevent the developer from managing the application before the current day we avoid using the preprocessing command DATE in any file because it does not always occur the rebuild, files already compiled are not recompiled.

Then we included in the pre-build script a script that simply creates a file with a current date record in a value of #define. This file is generated whenever there is a new build.

example of the generated file content (data_compilation. h):

#define DATA_COMPILACAO "20/02/19"

If the day changes, the #define is changed. Otherwise, the file remains unchanged except by file timestamp.

When I run git status in this scenario with no value change from #define, the file has no real changes - just a file timestamp update.

There is the possibility to include the file in . gitignore but would like to know if there is another way to configure Git to ignore file timestamp changes.

Is there a way to set up git for this? How could I handle this situation?

Thanks for the help.

  • 2

    If I understand correctly, add the file that is changed to the .gitignore wouldn’t solve your problem??

  • 2

    Can you explain why there is such a date and time change in the code, please? If you are not changing the code, it needs to exist?

  • 1

    From what you explain, this file must be a file generated by some build script - maybe to assign version, or something like that. So, my recommendation is that all generated files - including this one - stay on .gitignore

  • @Gabrielhardoim adding the file to . gitignore will prevent the file from being added to the commit in any situation. What I am looking for is a way of ignoring amendments based on some form of rule. Only important changes that do not involve changing the file timestamp for example.

  • @egomesbrandao There is a change because the pre-build script is configured to generate a file containing the current date. This approach was decided instead of using a pre-processing command such as DATE to prevent the developer generating the build from not generating an application with the old date. (it may occur that the developer does not recompile the file with the DATE, understands?)

  • 1

    What is this DATE file for? For version number?

  • @Leonardoalvesmachado I understand. was the suggestion of Gabrielhardoim too. I will adopt this suggestion for now. I’ll keep looking for a way to bypass file timestamp changes, there must be some way. Thanks to all comments so far. ^^

  • @egomesbrandao there is no file with the DATE. What I mentioned above was that nay use the approach of a file containing DATE. Instead, we use another approach, the pre-build script creates a file containing the #define of the current date. The problem is that even if the date doesn’t change, the date of the archive gets a different timestamp.

  • 3

    What I want to know is more about this process, what the purpose... Why I think it is a matter of concept: In source code, any change must be registered, you are changing the code, but from what I understand this change is irrelevant... So if it’s irrelevant, why does it happen? I think this pre-build process should be changed. Can you talk more about it, please, so we can help you better?

  • @egomesbrandao I edited the description with more details of the process. Already taking into account the suggestion to add the file in . gitignore.

  • @Wallanrocha do not remember very well the type Date in C, but he does not have the schedule, too? Wouldn’t it be expensive to compare only the date part? Well, I don’t quite understand... But giving a hint, if the previous paragraph does not work... The build should be performed in a centralized location, in this location, would be stamped the binary version. Since you use Git, it would be interesting to use the Git version, and that would no longer be necessary. This also if you are in a continuous integration process, the versions that you do not use, or that do not go into production plays out.

  • 1

    @egomesminded the DATE no time. Yes, I am entering only the date. I understood that the script will recreate the file even if it does not change the date, so your suggestion is very valid, I will search for a way to avoid (already in the pre-build script) that the file is recreated when do not change the date. Thanks for the suggestion, I’ll shift the search focus to the script, and leave git configured with . gitignore for now.

  • 1

    @Wallanrocha Take a look at this: https://stackoverflow.com/a/16244970/10226260 I hope it helps you

Show 8 more comments

2 answers

1

Come on, I’ve been doing some research and I’ll try to summarize it here.

  • First: Create the file .gitattributes at the root of the project or create the file attributes in the directory .git/info/. (From what I understand, the first will be able to be committed and the other not)

  • Second: Add to file by creating a line that defines the filter.

    Ex: In files that end with *.txt use 'Shazam name filter'.

     *.txt filter=shazam
    
  • Third: Set settings on .gitconfig.

     git config filter.shazam.clean "sed '/shazam/g'"
    

So, execute the command git commit -m "Mensagem" --all so that it commits the file by executing the instruction passed to the clean. This configuration was done locally, but you can use the --global. Beyond the clean has also the smudge but I still don’t understand the difference between them.

  • 1

    Thank you very much for your contribution. At the time the solution I adopted was to change the pre-build script to create the file again only if the date was changed, so I checked in the script a way to read the file and get the date information. It is not the most elegant but it meets. Now with more time I will follow your suggestion of filters, I do not understand 100% and I will start to search. Again, thank you so much.

1


The GIT does not consider different timestamps as file change. What he may consider different is:

  • end of different line in different systems;
  • changed permissions in the archive;
  • any other character not normally displayed in editors;

The first item is highlighted because in most cases it is the culprit. In a Windows system, it is used CRLF and *Nix LF. More information about these differences in the article "Newline" of Wikipedia (in English).

Many Windows editors or automatically change the LF for CRLF or add both. So, if the code goes from system to system, it starts these problems that you’re having.

Solution

You must be in an environment with several types of OS being used. So, perform the steps below to fix line jump issues:

1 - No Windows, execute:

git config --global core.autocrlf true

2 - No Linux or Mac, execute:

git config --global core.autocrlf input 

Reading suggestion: "Formatting and Whitespace", in the section "core.autocrlf". But the content is in English.

  • 1

    Thank you so much for your contribution. This change in the shape of the line break is taking place, your suggestion was very helpful. The reading suggestion helped a lot too.

  • 1

    @Wallanrocha opa, no problem! If the answer solved your problem, mark the answer as a solution to close the question and help other people with similar problems! Otherwise, comment so we can change and then see what we can help.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.