Menu
▾
▴
gnuplot-beta
|
From: sfeam <sf...@us...> - 2017-12-25 19:12:09
|
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. 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? Ethan |
|
From: Bastian M. <bma...@we...> - 2017-12-25 21:08:32
|
> 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. That might do the trick: git log -1 --format=%ci | cut -b-10 Bastian > > On that note, I see that git commits keep their original date > (of construction?) rather than the date they were committed. > 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? > > Ethan |
|
From: sfeam <sf...@us...> - 2017-12-25 21:56:13
|
On Monday, 25 December 2017 22:08:24 Bastian Märkisch 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.
>
> That might do the trick:
> git log -1 --format=%ci | cut -b-10
>
> Bastian
That looks promising.
Can someone wrap that in the appropriate Makefile syntax to
substitute for the rule currently in src/Makefile.am?
timestamp.h: $(top_srcdir)/ChangeLog Makefile
@echo Making $@
@echo "#ifndef GNUPLOT_TIMEBASE_H_INCLUDED" >$@t
@echo "#define GNUPLOT_TIMEBASE_H_INCLUDED" >>$@t
@head -1 $< | sed -e 's,\(^[0-9-]* \).*$$,const char gnuplot_date[] = "\1";,' >>$@t
@echo "#endif /* GNUPLOT_TIMEBASE_H_INCLUDED */" >> $@t
@if cmp -s $@ $@t; then rm -f $@t; else mv $@t $@; fi
I suppose the dependency rule would become something like
timestamp.h: $(top_srcdir)/.git/objects Makefile
but how does one get "make" to track the change status of .git/objects ?
Ethan
|
|
From: Daniel J S. <dan...@ie...> - 2017-12-25 21:19:43
|
On 12/25/2017 01:10 PM, 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. > 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? There are two dates, author and commit. Explore https://www.git-scm.com/docs/git-log#_pretty_formats and format the spacing, date contents, etc. the way desired. Here's a start (the %cd stands for "commit date"): git log --all --format='Author: %an <%ae>%nCommit Date: %cd%n%n %s%n%n %b' Dan |
|
From: Mojca M. <moj...@gm...> - 2017-12-25 21:20:19
|
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. Mojca |
|
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
|
|
From: Bastian M. <bma...@we...> - 2017-12-25 23:23:25
|
Forgot to reply to the list. > > On Monday, 25 December 2017 22:08:24 Bastian Märkisch 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. > > > > > > That might do the trick: > > > git log -1 --format=%ci | cut -b-10 > > > > > > Bastian > > > > That looks promising. > > Can someone wrap that in the appropriate Makefile syntax to > > substitute for the rule currently in src/Makefile.am? > > > > timestamp.h: $(top_srcdir)/ChangeLog Makefile > > @echo Making $@ > > @echo "#ifndef GNUPLOT_TIMEBASE_H_INCLUDED" >$@t > > @echo "#define GNUPLOT_TIMEBASE_H_INCLUDED" >>$@t > > @head -1 $< | sed -e 's,\(^[0-9-]* \).*$$,const char gnuplot_date[] = "\1";,' >>$@t > > @echo "#endif /* GNUPLOT_TIMEBASE_H_INCLUDED */" >> $@t > > @if cmp -s $@ $@t; then rm -f $@t; else mv $@t $@; fi > > > > > > > > I suppose the dependency rule would become something like > > > > timestamp.h: $(top_srcdir)/.git/objects Makefile > > > > but how does one get "make" to track the change status of .git/objects ? > > > > Ethan > > > Pleae find below my attempt on a solution. Note that the dependency > "trick" is taken from > http://www.howtobuildsoftware.com/index.php/how-do/ceio/git-makefile-hook-track-branch-changes-from-a-makefile > > Bastian > > diff --git a/src/Makefile.am b/src/Makefile.am > index 0af79fe..9c57550 100644 > --- a/src/Makefile.am > +++ b/src/Makefile.am > @@ -105,11 +105,12 @@ endif > > DISTCLEANFILES = timestamp.h > BUILT_SOURCES = timestamp.h > -timestamp.h: $(top_srcdir)/ChangeLog Makefile > +git_current := $(shell cut -c6- $(top_srcdir)/.git/HEAD) > +timestamp.h: $(top_srcdir)/.git/${git_current} Makefile > @echo Making $@ > @echo "#ifndef GNUPLOT_TIMEBASE_H_INCLUDED" >$@t > @echo "#define GNUPLOT_TIMEBASE_H_INCLUDED" >>$@t > - @head -1 $< | sed -e 's,\(^[0-9-]* \).*$$,const char gnuplot_date[] = "\1";,' >>$@t > + @echo "const char gnuplot_date[] = \"`git log -1 --format=%ci | cut -b-11`\";" >>$@t > @echo "#endif /* GNUPLOT_TIMEBASE_H_INCLUDED */" >> $@t > @if cmp -s $@ $@t; then rm -f $@t; else mv $@t $@; fi > |
|
From: Dima K. <gn...@di...> - 2017-12-26 08:53:04
|
(accidentally hit "send" prematurely. Trying again.) Bastian Mrkisch <bma...@we...> writes: > @echo "#ifndef GNUPLOT_TIMEBASE_H_INCLUDED" >$@t > @echo "#define GNUPLOT_TIMEBASE_H_INCLUDED" >>$@t > - @head -1 $< | sed -e 's,\(^[0-9-]* \).*$$,const char gnuplot_date[] = "\1";,' >>$@t > + @echo "const char gnuplot_date[] = \"`git log -1 --format=%ci | cut -b-11`\";" >>$@t > @echo "#endif /* GNUPLOT_TIMEBASE_H_INCLUDED */" >> $@t > @if cmp -s $@ $@t; then rm -f $@t; else mv $@t $@; fi Presumably this will barf when building from a release tarball WITHOUT the git metadata (i.e. what the distros do), right? Or is timestamp.h not built in those cases? |
|
From: Dima K. <gn...@di...> - 2017-12-26 08:58:03
|
Bastian Mrkisch <bma...@we...> writes:
> diff --git a/src/Makefile.am b/src/Makefile.am
> index 0af79fe..9c57550 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -105,11 +105,12 @@ endif
>
> DISTCLEANFILES = timestamp.h
> BUILT_SOURCES = timestamp.h
> -timestamp.h: $(top_srcdir)/ChangeLog Makefile
> +git_current := $(shell cut -c6- $(top_srcdir)/.git/HEAD)
> +timestamp.h: $(top_srcdir)/.git/${git_current} Makefile
> @echo Making $@
> @echo "#ifndef GNUPLOT_TIMEBASE_H_INCLUDED" >$@t
> @echo "#define GNUPLOT_TIMEBASE_H_INCLUDED" >>$@t
> - @head -1 $< | sed -e 's,\(^[0-9-]* \).*$$,const char gnuplot_date[] = "\1";,' >>$@t
> + @echo "const char gnuplot_date[] = \"`git log -1 --format=%ci | cut -b-11`\";" >>$@t
> @echo "#endif /* GNUPLOT_TIMEBASE_H_INCLUDED */" >> $@t
> @if cmp -s $@ $@t; then rm -f $@t; else mv $@t $@; fi
|
|
From: Bastian M. <bma...@we...> - 2017-12-26 09:32:53
|
> Von: "Dima Kogan" <gn...@di...> > > Bastian M�rkisch <bma...@we...> writes: > > @echo "#ifndef GNUPLOT_TIMEBASE_H_INCLUDED" >$@t > > @echo "#define GNUPLOT_TIMEBASE_H_INCLUDED" >>$@t > > - @head -1 $< | sed -e 's,\(^[0-9-]* \).*$$,const char gnuplot_date[] = "\1";,' >>$@t > > + @echo "const char gnuplot_date[] = \"`git log -1 --format=%ci | cut -b-11`\";" >>$@t > > @echo "#endif /* GNUPLOT_TIMEBASE_H_INCLUDED */" >> $@t > > @if cmp -s $@ $@t; then rm -f $@t; else mv $@t $@; fi > > Presumably this will barf when building from a release tarball WITHOUT > the git metadata (i.e. what the distros do), right? Or is timestamp.h > not built in those cases? At least it wouldn't need to be built. It's only included by src/version.c for the development version. Instead, the date is hard-coded there. Bastian |
|
From: Bastian M. <bma...@we...> - 2017-12-26 10:21:05
|
> Von: "Bastian Märkisch" <bma...@we...> > > Von: "Dima Kogan" <gn...@di...> > > > Bastian M�rkisch <bma...@we...> writes: > > > @echo "#ifndef GNUPLOT_TIMEBASE_H_INCLUDED" >$@t > > > @echo "#define GNUPLOT_TIMEBASE_H_INCLUDED" >>$@t > > > - @head -1 $< | sed -e 's,\(^[0-9-]* \).*$$,const char gnuplot_date[] = "\1";,' >>$@t > > > + @echo "const char gnuplot_date[] = \"`git log -1 --format=%ci | cut -b-11`\";" >>$@t > > > @echo "#endif /* GNUPLOT_TIMEBASE_H_INCLUDED */" >> $@t > > > @if cmp -s $@ $@t; then rm -f $@t; else mv $@t $@; fi > > > > Presumably this will barf when building from a release tarball WITHOUT > > the git metadata (i.e. what the distros do), right? Or is timestamp.h > > not built in those cases? > > At least it wouldn't need to be built. It's only included by src/version.c for the development > version. Instead, the date is hard-coded there. > > Bastian FWIW I put a merge request on SF: https://sourceforge.net/p/gnuplot/gnuplot-main/merge-requests/4/ |
