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 |