Re: commit 9d0f14

[Tatsuro M. <tma...@ya...>]

----- Original Message -----

> From: Mojca Miklavec 
> To: Ethan Merritt 
> Cc: gnuplot-beta ; Ethan A Merritt
> Date: 2018/3/23, Fri 05:16
> Subject: Re: commit 9d0f14
> 
> On 22 March 2018 at 19:26, Ethan Merritt wrote:
>> 
>>  Here's a different idea.
>>  Does git gurantee to preserve the modification date attribute of files in
>>  the repository?
> 
> I'm not sure what you are asking exactly, but:
> 
> - Git doesn't remember original modification time of any file. That
> is: you cannot take a file that was last modified on March 1st, commit
> it today, clone repository and get that info about the 1st of March in
> any way. The original modification timestamp is lost.
> - What git *does* remember is commit timestamp, or rather two
> timestamps, timestamp of when the author committed this first and then
> another timestamp in case of further
> modifications/merging/rebasing/cherry-picking etc. (git calls that
> "author" and "committer" timestamp; you can manually specify 
> those
> timestamps of course, but that's a different issue)
> 
> When you switch back and forth between branches, the last modification
> time of files on the disk will change, I think.
> 
> There is a way to enforce a consistent timing with a built-in function
> to generate tarbals for example, but I don't think you can rely on
> that feature unless you take some special care. By default all the
> files you check out will have the timestamp of the time when you
> cloned repository or pulled in new changes or switched between
> branches rather than the timestamp of the actual change in repository.
> 
>>  I observe that it does this in practice, but maybe it is not a guarantee.
>>  We don't really need to alter the _contents_ of a timestamp file,  just 
> its
>>  modification date.
> 
> See above, I don't believe this would in practice be any less random
> than the build timestamp. Ok, at least it will be reproducible on the
> same machine, so slightly less randomness :)
> 
> Here are some ideas:
>   
> https://stackoverflow.com/questions/1704907/how-can-i-get-my-c-code-to-automatically-print-out-its-git-version-hash
> 
> If the only problem of "git describe" is support for out-of-source
> builds, couldn't the Makefile simply do something like
> 
>     # remember current build-dir
>     cd source-dir
>     version=`git describe ...`
>     cd build-dir
>     echo $version > versionfile.txt
> 
> (consider this to be pseudo-code). If git fails in this case, then go
> for version written elsewhere of course.
> 
> Mojca
> 


In my opinion, for development version of open source software, 
git or mercurial version hash is essential.

I vote to the Mojca's proposal.

Tatsuro