|
From: Daniel J S. <dan...@ie...> - 2017-12-26 02:14:10
|
On 12/25/2017 03:20 PM, Mojca Miklavec wrote:
> On 25 December 2017 at 20:10, sfeam via gnuplot-beta wrote:
>> Building from git tip fails to insert a valid date into
>> the "last modified" field. This used to be pulled from the
>> top of ChangeLog and inserted into timestamp.h but that
>> mechanism does not track the date of git commits.
>>
>> On that note, I see that git commits keep their original date
>> (of construction?) rather than the date they were committed.
>
> There are two separate dates. Author date and committer date. I don't
> know how SourceForge works, but on GitHub at least the committer date
> would correspond to the timestamp of clicking the "merge" button of
> pull requests. Still, that doesn't help with you committing your local
> changes directly.
>
>> That means "git log" returns non-sequential dates in the
>> history of changes. That does not seem like a great idea.
>> Is there a setting somewhere that tells git to stamp each
>> commit with the current date instead?
>
> No. Git is a distributed version control system and it doesn't treat
> SourceForge any different from your local repository.
>
> Note that before pushing anything to the public repository you can
> arbitrarily change both author and commit timestamps of any given
> commit (you can prepare a script that will fix anything you want), but
> you cannot enforce any special setting on the server.
>
> If you committed something 10 days ago and the development on
> SourceForge was active in the meantime, your local commit will not be
> modified, at least not automatically. If you rebase your commit, the
> author date (the one you see) will stay 10 days behind, only the
> commit date will change to match the timestamp of when you ran the
> rebase.
>
> I'm pretty sure that it's possible for you to set up something locally
> that will modify the timestamps of your own commits before pushing to
> SourceForge, but that doesn't guarantee that any other developer will
> do the same and there's probably nothing you can do about it (short of
> being the only one with commit rights).
>
> Also, if you cherry-pick commits from master branch to some stable
> branch, the author dates will not change.
This may be why some groups devise a strategy like doing personal
development in separate branches then merge the branch to the master or
stable. Is there a new commit date associated with the merge? That
way, if one is interested in only the master branch, say, then the log
can be filtered for that:
linux@ ~/gnuplot/git_repository/gnuplot-git $ git log --branches=master
| grep '5\.2\.2'
linux@ ~/gnuplot/git_repository/gnuplot-git $ git log --all | grep '5\.2\.2'
Bump version to 5.2.2
where 5.2.2 is on a separate branch from master.
Dan
|