meaning of "Automatic date update in version.in" commits

[Matthias Klose]

On 21.09.2017 17:46, Petr Ovtchenkov wrote:
> On Thu, 21 Sep 2017 15:25:53 +0200
> Simon Marchi <simon.marchi@polymtl.ca> wrote:
> 
>> On 2017-09-21 15:17, Petr Ovtchenkov wrote:
>>> And date stamp in version.in not play here at all. But,
>>>
>>>   - if you insert date stamp into sources, you
>>>     i)  keep "litter" problem
>>>     ii) make misorientation (what this date mean? commit date? - it 
>>> already
>>>        present in commit; and what commit date?)
>>>   - if you don't insert date stamp into sources, but add to SONAME
>>> during build process,
>>>     it still not reflect ABI compatibilities, but may prevent "binary
>>> reproducible builds"
>>>     (depends upon what date you use). I'm underline, that such addition
>>>     has no relation to ABI compatibilities, so such SONAME modification
>>>     lose sense.
>>
>> Binary reproducible builds mean that if you and I start with the same 
>> source code and same build tools, we will get exactly the same build 
>> artifacts.  Here the build can't "depend on what date you use":
> 
> If "date stamp" inserted into binary is a build date, then we will have different
> binaries.

but it not a build date. it is a string taken form a file in the repository.
That's exactly what Simon wrote at the end of the last message, and which you
ignored to read or comment. Please see below.

> If we will use something else, for example "last commit" date,
> then we may have "same" build, but may not. From equality of "last commit" date
> not follow binary equivalence (consider cherry-picked commit, for example,
> or variations of sample "git diff 3110f4be18a2 f625a739" I show above).
> 
>> you 
>> can't choose a date or another, the date is part of the code you are 
>> trying to build.  So if you and I build from the same commit, we'll 
>> build using the same date, whatever date is in the version.h file.
>>
>>