gnuplot-beta — Developers and beta testers of new gnuplot code

Re: git equivalent to pulling the most recent date from ChangeLog?

[Daniel J S. <dan...@ie...>]

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

Fw: Aw: Re: git equivalent to pulling the most recent date from ChangeLog?

[Bastian M. <bma...@we...>]

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
>

Re: Aw: git problem: "insufficient permission"

[sfeam <sf...@us...>]

On Monday, 25 December 2017 22:19:23 Bastian Märkisch wrote:
> > All of a sudden I am getting the following error when I try to
> > push to gnuplot-main on SourceForge.   Any ideas?
> 
> I was seeing this, too.  Might be related to some SF outage - I am experiencing some error 500 for the web pages.
> It is working for now again for me.  Did you do anything to fix it?

I'm not sure.
  
I went to the URL
   https://sourceforge.net/p/gnuplot/gnuplot-main/ci/master/tree/
and when I tried to select a file to look at this triggered a spinning
icon with a message "re-analyzing repository".   When the operation
finished, things were back to normal. I don't know if that
happened only because I am a project admin and tried to access a file
or whether the same thing would have happened anyway.  
 
> Btw. where is the repo located. Can it be accessed via SF shell access?

Yes.
	ssh -t user,gn...@sh... create
    cd /home/git/p/gnuplot
    file *
		gnuplot-main.git: directory


	Cheers,

		Ethan

   
> Merry Christmas,
> 
>   Bastian
> 

Re: Aw: git equivalent to pulling the most recent date from ChangeLog?

[sfeam <sf...@us...>]

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

Re: git equivalent to pulling the most recent date from ChangeLog?

[Mojca M. <moj...@gm...>]

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

Re: git equivalent to pulling the most recent date from ChangeLog?

[Daniel J S. <dan...@ie...>]

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

Aw: git problem: "insufficient permission"

[Bastian M. <bma...@we...>]

> All of a sudden I am getting the following error when I try to
> push to gnuplot-main on SourceForge.   Any ideas?

I was seeing this, too.  Might be related to some SF outage - I am experiencing some error 500 for the web pages.
It is working for now again for me.  Did you do anything to fix it?

Btw. where is the repo located. Can it be accessed via SF shell access?
  
Merry Christmas,

  Bastian

> 
> stonelion [931] git push
> Counting objects: 4, done.
> Delta compression using up to 4 threads.
> Compressing objects: 100% (4/4), done.
> Writing objects: 100% (4/4), 693 bytes | 0 bytes/s, done.
> Total 4 (delta 3), reused 0 (delta 0)
> remote: error: insufficient permission for adding an object to repository database ./objects
> remote: fatal: failed to write object
> error: unpack failed: unpack-objects abnormal exit
> To ssh://sfeam@git.code.sf.net/p/gnuplot/gnuplot-main
>  ! [remote rejected] master -> master (unpacker error)
> error: failed to push some refs to 'ssh://sfeam@git.code.sf.net/p/gnuplot/gnuplot-main'
> 
> stonelion [932] git status
> On branch master
> Your branch is ahead of 'origin/master' by 1 commit.
>   (use "git push" to publish your local commits)
> nothing to commit, working directory clean
> 
> stonelion [933] git fetch
> 
> 
> 		other than that,
> 
> 			Merry Christmas
> 
> 				Ethan
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Aw: git equivalent to pulling the most recent date from ChangeLog?

[Bastian M. <bma...@we...>]

> 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

git equivalent to pulling the most recent date from ChangeLog?

[sfeam <sf...@us...>]

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

git problem: "insufficient permission"

[sfeam <sf...@us...>]

All of a sudden I am getting the following error when I try to
push to gnuplot-main on SourceForge.   Any ideas?

stonelion [931] git push
Counting objects: 4, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 693 bytes | 0 bytes/s, done.
Total 4 (delta 3), reused 0 (delta 0)
remote: error: insufficient permission for adding an object to repository database ./objects
remote: fatal: failed to write object
error: unpack failed: unpack-objects abnormal exit
To ssh://sfeam@git.code.sf.net/p/gnuplot/gnuplot-main
 ! [remote rejected] master -> master (unpacker error)
error: failed to push some refs to 'ssh://sfeam@git.code.sf.net/p/gnuplot/gnuplot-main'

stonelion [932] git status
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)
nothing to commit, working directory clean

stonelion [933] git fetch


		other than that,

			Merry Christmas

				Ethan

Documentation: help string variables

[Lutz M. <lut...@gm...>]

When I type “help string” in gnuplot 5.2.2 I get the message

Ambiguous request 'string'; possible matches:
	string variables
	stringcolumn
	strings

However, the section “string variables” seems inaccessible; as “help string variables” just returns the same message, and “help strings” doesn’t seem to have a subsection “variables”.

Best,

Lutz

Re: Aw: Re: Re: AW: Status update - version 5.2.2, cvs->git conversion, plans

[sfeam <sf...@us...>]

On Sunday, 19 November 2017 21:54:41 Bastian Märkisch wrote:
> > Gesendet: Sonntag, 19. November 2017 um 21:10 Uhr
> > Von: sfeam <sf...@us...>
> > On Sunday, 19 November 2017 20:39:57 Bastian Märkisch wrote:
> > 
> > > Although the "setfield" lines now work, adding such statements to reconvert seems to 
> > > break the repository conversion:
> > > 
> > > reposurgeon: exporting...fatal: Expected committer but didn't get opne
> > > 
> > > I am giving up. The automatic ChangeLog conversion does a great job. As far as I can 
> > > tell there are <100 manual attribution changes we could argue about.
> > > 
> > > Ethan,  the repo "gnuplot-trunk" was in my opinion converted using an older version
> > > of Eric Raymond's script which got the attribution wrong if the ChangeLog change did
> > > not include the author line.  There are quite a number of these.  E.g. there are ~120
> > > of your committs which claim I am the author. But this is only true for very few of
> > > them:
> > > git log --committer=Ethan --author=Bastian --oneline
> > > So - in my opinion - one further iteration of conversion is in order.
> > 
> > I used a version that Eric sent me on 04-Nov-2017.
> > I have not seen a newer version.  
> > Is there one?
> > 
> > 	Ethan
> > 
> 
> Hhm.  The version I have is 4-Nov-2017, too.  But then again the above git log command
> only gives me 19 entries when I convert locally.

I ran the conversion again using the same "reconvert" version (4 Nov)
but newer versions of reposurgeon/repotool (11 Nov).
That seems to make the difference.
I have pushed this hopefully final copy of the converted repository to
sf.net as

   git.code.sf.net/p/gnuplot/gnuplot-main

The previous attempt (gnuplot-trunk) is still there on sf.net for my
reference as I re-apply patches subsequent to its initial state.

Please use "gnuplot-main" as of now.
I will probably delete the older one tomorrow.

	Ethan

Aw: Re: Re: AW: Status update - version 5.2.2, cvs->git conversion, plans

[Bastian M. <bma...@we...>]

> Gesendet: Sonntag, 19. November 2017 um 21:10 Uhr
> Von: sfeam <sf...@us...>
> On Sunday, 19 November 2017 20:39:57 Bastian Märkisch wrote:
> 
> > Although the "setfield" lines now work, adding such statements to reconvert seems to 
> > break the repository conversion:
> > 
> > reposurgeon: exporting...fatal: Expected committer but didn't get opne
> > 
> > I am giving up. The automatic ChangeLog conversion does a great job. As far as I can 
> > tell there are <100 manual attribution changes we could argue about.
> > 
> > Ethan,  the repo "gnuplot-trunk" was in my opinion converted using an older version
> > of Eric Raymond's script which got the attribution wrong if the ChangeLog change did
> > not include the author line.  There are quite a number of these.  E.g. there are ~120
> > of your committs which claim I am the author. But this is only true for very few of
> > them:
> > git log --committer=Ethan --author=Bastian --oneline
> > So - in my opinion - one further iteration of conversion is in order.
> 
> I used a version that Eric sent me on 04-Nov-2017.
> I have not seen a newer version.  
> Is there one?
> 
> 	Ethan
> 

Hhm.  The version I have is 4-Nov-2017, too.  But then again the above git log command
only gives me 19 entries when I convert locally.

  Bastian

Re: Aw: Re: AW: Status update - version 5.2.2, cvs->git conversion, plans

[sfeam <sf...@us...>]

On Sunday, 19 November 2017 20:39:57 Bastian Märkisch wrote:

> Although the "setfield" lines now work, adding such statements to reconvert seems to 
> break the repository conversion:
> 
> reposurgeon: exporting...fatal: Expected committer but didn't get opne
> 
> I am giving up. The automatic ChangeLog conversion does a great job. As far as I can 
> tell there are <100 manual attribution changes we could argue about.
> 
> Ethan,  the repo "gnuplot-trunk" was in my opinion converted using an older version
> of Eric Raymond's script which got the attribution wrong if the ChangeLog change did
> not include the author line.  There are quite a number of these.  E.g. there are ~120
> of your committs which claim I am the author. But this is only true for very few of
> them:
> git log --committer=Ethan --author=Bastian --oneline
> So - in my opinion - one further iteration of conversion is in order.

I used a version that Eric sent me on 04-Nov-2017.
I have not seen a newer version.  
Is there one?

	Ethan

Aw: Re: AW: Status update - version 5.2.2, cvs->git conversion, plans

[Bastian M. <bma...@we...>]

> > > What I have been trying to do is to manually add author changes to the Eric
> > > Raymond's reconvert script.  The example command given was:
> > >   <es...@th...!2017-11-04T16:44:25> setfield author "Frd J. Foonly
> > > <fr...@fo...>"
> > > (which according to the docs probably should instead be
> > > <2017-11-04T16:44:25! es...@th...> setfield author "Frd J. Foonly
> > > <fr...@fo...>"
> > > 
> > > Unfortunately, such commands do not "find" the entry, not even with the tip
> > > version of reposurgeon.
> > > So I am kind of stuck for the moment.
(snip)
> > You are likely running into what I ran into with experimenting with 
> > tags, the time-zone factor.  You must specify the exact time in the 
> > search field <>, but often git displays some kind of time zone-adjusted. 
> >   So I had to do trial and error shifting by 7 hours to put times in 
> > GMT, e.g., <2013-04-11T20:04:07Z>.  (Note the added Z...search Zulu time 
> > in Wikipedia:
> > 
> > https://en.wikipedia.org/wiki/Time_zone
> > 
> > )
> > 
> > For example, doing the git log as you suggested, I see a time
> > 
> > 2000-10-20T20:01:32+01:00
> > 
> > which would be
> > 
> > 2000-10-20T20:01:32Z
> > 
> > I think.  Anyway, I used git times from qgit that didn't have that extra 
> > UTC offset value so I often had to compute the proper UTC time and 
> > rarely got it right on the first try.
> > 
> > Dan
> 
> That did the trick! You just have to subtract the time offset to get the "Zulu" time.
> Thanks for the pointer.  I thought I had tried that before though....
> 
>    Bastian
> 

Although the "setfield" lines now work, adding such statements to reconvert seems to 
break the repository conversion:

reposurgeon: exporting...fatal: Expected committer but didn't get opne

I am giving up. The automatic ChangeLog conversion does a great job. As far as I can 
tell there are <100 manual attribution changes we could argue about.

Ethan,  the repo "gnuplot-trunk" was in my opinion converted using an older version
of Eric Raymond's script which got the attribution wrong if the ChangeLog change did
not include the author line.  There are quite a number of these.  E.g. there are ~120
of your committs which claim I am the author. But this is only true for very few of
them:
git log --committer=Ethan --author=Bastian --oneline
So - in my opinion - one further iteration of conversion is in order.

  Bastian

Re: Another git question

[Tait <gnu...@t4...>]

sfeam <sf...@us...> said (on 2017/11/18):
> ...
> The key was realizing that it was OK to specify commit id's that
> were not currently showing in the display, since a different
> branch was selected.

I almost always invoke gitk as "gitk --all" so that I can see
all the branches instead of just what's currently checked-out.

Re: Another git question

[Achim G. <Str...@ne...>]

Ethan A Merritt via gnuplot-beta writes:
> Unfortunately (4) will never work as-is because the ChangeLog is
> very different between the two branches.  On the other hand I know
> that the modification to the ChangeLog is always at the top,
> so I edit the formatted patch as I showed so that the ChangeLog diffs
> refer specifically to the top of the file.

There are specialized merge drivers for ChangeLog files and similar
things you can tell git to use that use those peculiarities to produce
less merge conflicts.

> Is there some totally different recommended way to replicate
> changes previously made to one branch and apply them to a 
> different branch?

What's wrong with cherry-pick, specifically the form that uses a range
expression for the commits?  If the changes are already in the repo, I
never bother with git format-patch / am.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Aw: Re: AW: Status update - version 5.2.2, cvs->git conversion, plans

[Bastian M. <bma...@we...>]

> > What I have been trying to do is to manually add author changes to the Eric
> > Raymond's reconvert script.  The example command given was:
> >   <es...@th...!2017-11-04T16:44:25> setfield author "Frd J. Foonly
> > <fr...@fo...>"
> > (which according to the docs probably should instead be
> > <2017-11-04T16:44:25! es...@th...> setfield author "Frd J. Foonly
> > <fr...@fo...>"
> > 
> > Unfortunately, such commands do not "find" the entry, not even with the tip
> > version of reposurgeon.
> > So I am kind of stuck for the moment.
> 
> There can't be a space in the search field <2017-11-04T16:44:25! 
> es...@th...>  I'm assuming you don't have any in what you are 
> searching for.

Sure. No spaces.

> 
> You are likely running into what I ran into with experimenting with 
> tags, the time-zone factor.  You must specify the exact time in the 
> search field <>, but often git displays some kind of time zone-adjusted. 
>   So I had to do trial and error shifting by 7 hours to put times in 
> GMT, e.g., <2013-04-11T20:04:07Z>.  (Note the added Z...search Zulu time 
> in Wikipedia:
> 
> https://en.wikipedia.org/wiki/Time_zone
> 
> )
> 
> For example, doing the git log as you suggested, I see a time
> 
> 2000-10-20T20:01:32+01:00
> 
> which would be
> 
> 2000-10-20T20:01:32Z
> 
> I think.  Anyway, I used git times from qgit that didn't have that extra 
> UTC offset value so I often had to compute the proper UTC time and 
> rarely got it right on the first try.
> 
> Dan

That did the trick! You just have to subtract the time offset to get the "Zulu" time.
Thanks for the pointer.  I thought I had tried that before though....

   Bastian

Aw: Status update - version 5.2.2, cvs->git conversion, plans

[Bastian M. <bma...@we...>]

> Version 5.2.2
> =============
> 
> A tarball for release 5.2.2 is now in the usual place on sf.net:
>      https://sourceforge.net/projects/gnuplot/files/gnuplot/5.2.2/
> This will be the last gnuplot release prepared from the CVS repository.
> 
> Anything you commit to cvs between now and whenever sourceforge pulls
> the plug on it will not make it into future gnuplot releases.
> 

Windows 32bit and 64bit binary packages are now available on SF as 
installer packages or in 7z format.

The installers claim a minimum requirement of Vista SP2 (but need
the "feature upgrade"), but this may or may not be true since I cannot
test.  Earliest version tested is Windows 7 SP2.

  Bastian

Re: Another git question

[sfeam <sf...@us...>]

On Friday, 17 November 2017 16:55:29 Dima Kogan wrote:
> Ethan A Merritt via gnuplot-beta <gnu...@li...> writes:
> 
> > The point of the operation is that it is not at the same revision.
> > What I'm trying to do is convert my usual workflow into git-speak.
> > New features are developed and tested against the development branch.
> > If they pan out, I go back and apply them to the stable branch.
> 
> I don't have time to do a lot of typing right now, but I'll answer the
> actual question.
> 
> You don't want to deal with patches to do this; you COULD, but it's more
> trouble than it's worth.
> 
> If you have two different trees (accessible as branches, tags, on a
> remote somehere, whatever), you can pull in individual arbitrary commits
> with 'git cherry-pick', or pull in whole chunks of the tree with 'git
> rebase' or 'git rebase --onto' if you need to be fancy. Clearly these
> operations can fail due to a conflict. It'll then stop and tell you what
> to do.
> 
> I'll type more tomorrow if you don't get it going by then.

I think I've got it now.
The ChangeLog file is still a problem, but yes 'get cherry-pick'
takes fewer steps than what I was doing before.  

The key was realizing that it was OK to specify commit id's that
were not currently showing in the display, since a different
branch was selected.

   thanks,

		Ethan

Re: Another git question

[Dima K. <gn...@di...>]

Ethan A Merritt via gnuplot-beta <gnu...@li...> writes:

> The point of the operation is that it is not at the same revision.
> What I'm trying to do is convert my usual workflow into git-speak.
> New features are developed and tested against the development branch.
> If they pan out, I go back and apply them to the stable branch.

I don't have time to do a lot of typing right now, but I'll answer the
actual question.

You don't want to deal with patches to do this; you COULD, but it's more
trouble than it's worth.

If you have two different trees (accessible as branches, tags, on a
remote somehere, whatever), you can pull in individual arbitrary commits
with 'git cherry-pick', or pull in whole chunks of the tree with 'git
rebase' or 'git rebase --onto' if you need to be fancy. Clearly these
operations can fail due to a conflict. It'll then stop and tell you what
to do.

I'll type more tomorrow if you don't get it going by then.

Re: Another git question

[Tait <gnu...@t4...>]

Ethan A Merritt <sf...@us...> said (on 2017/11/17):
> Are you thinking there is (or could be) a "master" branch that is
> different from "development"?  What would that gain us?

Sorry, I should have gone to look at the branch structure of the
existing repository on SF. "Master" is normally the main branch,
whatever that means. In my head, I was imagining that master was
the current release branch based on what you'd written before.

Having cloned https://git.code.sf.net/p/gnuplot/git-trunk now,
I'll try to use the branch names that are actually there. What
I see is a master branch, and *-stable branches corresponding to
each release, so "master" is the development branch, it looks
like. (Correct me if I'm wrong.)

> Under the model we have been using, most of the changes to the
> development branch never appear in the current stable branch. 
> Instead at some point we create a new stable branch and essentially
> freeze it except for bugfixes.  OK that's a bit of an overstatement. 
> Some relatively self-contained features can be added to the current
> stable branch, but normally only after they've been in the
> development branch for a while to shake out problems.
> That's the part I'm trying to figure out right now. 

When you say "development branch" I think (now) that you mean
master. Then, as with the branch-5-2-stable, you branch from
master and changes unique to 5.2 go on that branch. If some bug
fix on 5.2 also affects master, how does that fix get from 5.2
back to master? What kinds of things go onto branch-5-2-stable
that shouldn't go back to master?

> This is all new to me, but I think that the merge you describe is in
> a sense the  opposite of what I want to do.

Any of what I describe is bidirectional. Git does not care
whether you merge or cherry-pick from stable to development, or
from development to stable. Cherry-pick is really nothing more
than "copy and paste this commit". The only thing to keep
straight is that cherry-pick will "paste" the commit onto
whatever is currently checked out when you issue the command.

Re: Another git question

[Ethan A M. <sf...@us...>]

On Friday, November 17, 2017 2:38:58 PM PST Tait wrote:
> > ...
> > What I'm trying to do is convert my usual workflow into git-speak.
> > New features are developed and tested against the development branch.
> > If they pan out, I go back and apply them to the stable branch.
> > ...
> > Is there some totally different recommended way to replicate
> > changes previously made to one branch and apply them to a 
> > different branch?
> 
> You want to use merge as much as possible, but even when that
> doesn't work, I think you'll find "cherry-pick" is a much easier
> choice than format-patch/am.

Thanks for the pointer.  I will look into that next.

> What I'd try to do, were I you, is branch each new feature off
> the development branch. The feature-branch can be developed and
> thrown away or merged back into the development branch. At some
> point the development branch looks okay, and it gets merged back
> into master. Rinse, repeat.

That would be a drastically different work flow.

> Implied in this flow is that everything that ultimately survives
> on the development branch wants to be part of master. I don't
> know how true that is.

Under the model we have been using, most of the changes to the
development branch never appear in the current stable branch. 
Instead at some point we create a new stable branch and essentially
freeze it except for bugfixes.  OK that's a bit of an overstatement. 
Some relatively self-contained features can be added to the current
stable branch, but normally only after they've been in the
development branch for a while to shake out problems.
That's the part I'm trying to figure out right now. 

Are you thinking there is (or could be) a "master" branch that is
different from "development"?  What would that gain us?

> If you want to selectively choose commits to copy from the
> development branch to master, then check out master (the
> destination branch), open up gitk to identify the commits you
> want, and "git cherry-pick <sha1>" to copy those commits from
> where they are onto master. 

There is no separate "master".  Should there be?

> This is essentially a one-commit
> "rebase" operation. It's less preferred than merge, because you
> have two different SHA1 that reference the same changes in
> different places now, and that's more potential for conflict in
> a future merge, although git is pretty good about recognizing
> it's the same thing. But in any case, it's much easier than the
> round-trip to *.patch and back when you already have the source
> data in the repository.

This is all new to me, but I think that the merge you describe is in
a sense the  opposite of what I want to do.
I don't want to take (cherry-pick?) commits from a separate branch
and merge them into what will be the main trunk going forward. 
Instead I want to copy a few commits that are already part of the
main trunk and graft them back onto an old branch that will never
be merged.  Am I describing this correctly?

The man page for git-cherry-pick does not show any examples
of this, or at least I don't recognize how the examples it does show
would apply to this case.

> The cherry-pick might conflict, especially with the ChangeLog.
> Git will add the usual conflict markers, but it should be easy
> to resolve,  

Hmm. What I've seen so far is that if it fails I don't get conflict
markers.  I get error messages like "index match failed" and a
dump of the original patch.  But I've tried enough things at this
point that they blur together in my mind. 

> then "git add" the ChangeLog and "git commit" will
> be pre-populated with the author/commit information. (I think
> there's a "cherry-pick --abort" to back up and pretend you were
> never doing the cherry-pick in the first place.)

I know how to edit + add  + commit + re-edit + commit --amend
to fix up the conflicts. 
I was kind of hoping there were git tricks to make it easier. 

	Ethan

Re: Another git question

[Tait <gnu...@t4...>]

> ...
> What I'm trying to do is convert my usual workflow into git-speak.
> New features are developed and tested against the development branch.
> If they pan out, I go back and apply them to the stable branch.
> ...
> Is there some totally different recommended way to replicate
> changes previously made to one branch and apply them to a 
> different branch?

You want to use merge as much as possible, but even when that
doesn't work, I think you'll find "cherry-pick" is a much easier
choice than format-patch/am.

What I'd try to do, were I you, is branch each new feature off
the development branch. The feature-branch can be developed and
thrown away or merged back into the development branch. At some
point the development branch looks okay, and it gets merged back
into master. Rinse, repeat.

Implied in this flow is that everything that ultimately survives
on the development branch wants to be part of master. I don't
know how true that is.

If you want to selectively choose commits to copy from the
development branch to master, then check out master (the
destination branch), open up gitk to identify the commits you
want, and "git cherry-pick <sha1>" to copy those commits from
where they are onto master. This is essentially a one-commit
"rebase" operation. It's less preferred than merge, because you
have two different SHA1 that reference the same changes in
different places now, and that's more potential for conflict in
a future merge, although git is pretty good about recognizing
it's the same thing. But in any case, it's much easier than the
round-trip to *.patch and back when you already have the source
data in the repository.

The cherry-pick might conflict, especially with the ChangeLog.
Git will add the usual conflict markers, but it should be easy
to resolve, then "git add" the ChangeLog and "git commit" will
be pre-populated with the author/commit information. (I think
there's a "cherry-pick --abort" to back up and pretend you were
never doing the cherry-pick in the first place.)

Re: Another git question

[Ethan A M. <sf...@us...>]

On Friday, November 17, 2017 1:39:17 PM PST you wrote:
> Ethan A Merritt via gnuplot-beta <gnu...@li...> writes:
> 
> > The entire patch file containing this piece is rejected by "git apply"
> > or "git am", apparently because it does not like the syntax "@@ -0,0"
> > which diff/patch use to indicate "top of file".
> 
> -0,0 doesn't just indicate "top of file". It indicates that the file was
> empty prior to this patch. Was that the case here?

-0,0 +1,4 means replace 0 lines starting at line 0 with 4 lines starting at line 1.
This is true whether or not the file was originally empty.
-1,0 +1,4 means the same except that it fails or warns if applied against
an empty file.

> > I can apply the patch manually using "patch" and then run "git commit",
> > but this loses the commit message and author information that was in
> > the original formatted patch.
> >
> > Is there some config option for "git am" and/or "git apply" that tells
> > it to accept this syntax in a patch file?
> 
> Don't know off the top of my head. Generall 'git am' is used as the
> complement to 'git format', but that's not what you're doing. If you
> just did a 'git format' and then a 'git am' on the tree at the same
> revision, it MUST work.

The point of the operation is that it is not at the same revision.
What I'm trying to do is convert my usual workflow into git-speak.
New features are developed and tested against the development branch.
If they pan out, I go back and apply them to the stable branch.

I figured that in git this is equivalent to
1) git checkout origin
2)  git format-patch --start-number 1 XXX..YYY
where XXX was the commit in the development branch just before
addition of the feature in question and YYY the commit just after
3)  git checkout branch-5-2-stable
4)  git am < 0*.patch

Unfortunately (4) will never work as-is because the ChangeLog is
very different between the two branches.  On the other hand I know
that the modification to the ChangeLog is always at the top,
so I edit the formatted patch as I showed so that the ChangeLog diffs
refer specifically to the top of the file. 
The equivalent has always worked for me in the past for patches
generated by "diiff".  And it still works with the output from
"git format-patch"  so long as I apply the patch with "patch" rather than
with "git".  

The closest I have come is

  git am <0*.patch    # fails with error about patch format
  patch --no-backup < 0*patch
  git stage --all          # register the patched files in the staging area
  git am --continue  # works if I'm lucky but not always

Is there some totally different recommended way to replicate
changes previously made to one branch and apply them to a 
different branch?

	Ethan