How to ignore timestamp changes embed in files when committing
There is a program I'm using that generates files (*.c, *.h, *.xml, etc).
As all the files it generate consists of timestamp, when it comes to committing, it's been hard to clean my commit, to include only files with actual code changes.
I am thinking of creating a program that revert changes of files if only timestamp was changed. It would be rule based so if the keyword "timestamp" is detected, then it will ignore that line. Would this be a logical decision or is there a simpler way to resolve this issue. The timestamp is important so it won't be removed from file generation. Any input is appreciated.
As all the files it generate consists of timestamp, when it comes to committing, it's been hard to clean my commit, to include only files with actual code changes.
I am thinking of creating a program that revert changes of files if only timestamp was changed. It would be rule based so if the keyword "timestamp" is detected, then it will ignore that line. Would this be a logical decision or is there a simpler way to resolve this issue. The timestamp is important so it won't be removed from file generation. Any input is appreciated.
It seems a reasonable idea.
Just be sure to make the detection super specific.
Letting through the occasional failed detection would just be a minor irritation.
Rejecting a real change because of a faulty match to some other use of "timestamp" elsewhere in the file would be much worse.
If your timestamps follow say the CVS/SVN "$Id$" style, then this may be of interest.
https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes#Keyword-Expansion
I'm assuming that your SCM tool is git at this point.
If it isn't, say what you're using.
Just be sure to make the detection super specific.
Letting through the occasional failed detection would just be a minor irritation.
Rejecting a real change because of a faulty match to some other use of "timestamp" elsewhere in the file would be much worse.
If your timestamps follow say the CVS/SVN "$Id$" style, then this may be of interest.
https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes#Keyword-Expansion
I'm assuming that your SCM tool is git at this point.
If it isn't, say what you're using.
Thank you very much for the input, I'll make sure that the keyword would be unique enough to not cause any issue. And yes, I am using git.
Generally speaking, you should not commit generated files. You should only commit generator inputs and the files should be generated as part of the build process.
I agree with helios.
That said, if you still want to proceed, first place to look is the generator program itself.
if that is something you wrote, odds are it deletes the old and makes new copies rather than try to modify the old one. This makes the OS think it is an old file. I don't know if you could modify the generation program or if you would want to, but maybe it could somehow check what it is about to write vs what is already there and stop if no change. That would be easy, a buffer of the to be written file vs the current one.
in both windows and unix you can likely rig a C++ "system()" program or a shell script/batch file to make this work. What you can do is before generating the files, copy them into a temp folder.
then generate and you can run the OS tools for file comparison against the old copy. Files that have changes can be redirected into a text file name list.
then you can copy (or move?) the old files back over the new ones for unchanged files.
all that can be automated I believe, and in visual studio even added as a post-build command.
I don't think you need to try to write anything fancy here, in other words, but you can use tried and debugged tools and crank out a solution in short order.
That said, if you still want to proceed, first place to look is the generator program itself.
if that is something you wrote, odds are it deletes the old and makes new copies rather than try to modify the old one. This makes the OS think it is an old file. I don't know if you could modify the generation program or if you would want to, but maybe it could somehow check what it is about to write vs what is already there and stop if no change. That would be easy, a buffer of the to be written file vs the current one.
in both windows and unix you can likely rig a C++ "system()" program or a shell script/batch file to make this work. What you can do is before generating the files, copy them into a temp folder.
then generate and you can run the OS tools for file comparison against the old copy. Files that have changes can be redirected into a text file name list.
then you can copy (or move?) the old files back over the new ones for unchanged files.
all that can be automated I believe, and in visual studio even added as a post-build command.
I don't think you need to try to write anything fancy here, in other words, but you can use tried and debugged tools and crank out a solution in short order.
Last edited on
I think there can be good reasons to track generated files in source control, for example to easily diff the files between revisions as they change. But I don't think simply adding those automated RCS keywords qualifies a file as being considered "generated" for purposes of source control.
Unless you'll debug the generator, you should be tracking differences in the generator's input, not its output. If this is the reason to add generated files, then you should also add executables to the repository.
IMO the only reason to track generated files is to simplify the build process. I've done that for example with Bison-generated parsers because Bison is such a pain to use on Windows.
IMO the only reason to track generated files is to simplify the build process. I've done that for example with Bison-generated parsers because Bison is such a pain to use on Windows.
| then you should also add executables to the repository. |
But I see what you mean. I guess it is only about simplifying the build process, since it makes the input to the build be pre-generated files, instead of having to build the generator, then generate the output, then build the rest with the generated files. [Which is a flakier argument, more in favor of only putting the true source in source control.]
Last edited on
both windows and unix have a binary file compare, but all it does if I recall is say different or same. You certainly can't look at the differences and make a lot of sense of them.
Topic archived. No new replies allowed.