gnuplot-beta

Trial git repo is back up

[<es...@th...>]

Trial git repo is back up, with the conversion bug I previously noted fixed.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

In recent years it has been suggested that the Second Amendment
protects the "collective" right of states to maintain militias, while
it does not protect the right of "the people" to keep and bear arms.
If anyone entertained this notion in the period during which the
Constitution and the Bill of Rights were debated and ratified, it
remains one of the most closely guarded secrets of the eighteenth
century, for no known writing surviving from the period between 1787
and 1791 states such a thesis.
        -- Stephen P. Halbrook, "That Every Man Be Armed", 1984

Re: Trial git repo is back up

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

On 10/16/2017 01:17 PM, Eric S. Raymond wrote:
> Trial git repo is back up, with the conversion bug I previously noted fixed.

Generally, cloning seems to take longer than I had expected, given 
gnuplot is a rather lean project.  It could be that SourceForge is just 
slow.  The cloning seems "chunky" in the respect it loads a bunch of 
objects then sort of slows down; speeds up again, slows down.

I don't see any authorship mapping; everything seems to appear as the 
committer is the author.  For example, I've searched "git log" for 
"Sebald" and only see my name appear in ancillary comments.  Never is my 
name/address as gotten from the ChangeLog record in the authorship line.

Some entries near the beginning of the project, as viewed through gitg:

# Apr 15 1998, 20:16 Initial import of beta340.

In gitg, no file diffs appear.

# Apr 15 1998, 20:16 *** empty log message ***

In gitg, "Loading diff..." never resolves.

Dan

Re: Trial git repo is back up

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

On Monday, 16 October, 2017 13:42:30 Daniel J Sebald wrote:
> On 10/16/2017 01:17 PM, Eric S. Raymond wrote:
> > Trial git repo is back up, with the conversion bug I previously noted fixed.
> 
> Generally, cloning seems to take longer than I had expected, given 
> gnuplot is a rather lean project.  It could be that SourceForge is just 
> slow.  The cloning seems "chunky" in the respect it loads a bunch of 
> objects then sort of slows down; speeds up again, slows down.
> 
> I don't see any authorship mapping; everything seems to appear as the 
> committer is the author.  For example, I've searched "git log" for 
> "Sebald" and only see my name appear in ancillary comments.  Never is my 
> name/address as gotten from the ChangeLog record in the authorship line.

I see separate authorship attached to many of the commits,
but yes I agree that in your case it doesn't seem to have been picked up.
E.g.
  https://sourceforge.net/p/gnuplot/git-main/ci/ef67fa09f12cd5f4cc869f7231d9e1f9b14c43a0/

your name shows in the associated ChangeLog entry but
has not been propagated to the patchset itself.
Same for the next 5 most ChangeLog entries with your name.

So it does seem that your name in particular is failing to trigger a
match event in the annotation process. 

	Ethan

Re: Trial git repo is back up

[Eric S. R. <es...@th...>]

Ethan A Merritt <sf...@us...>:
> I see separate authorship attached to many of the commits,
> but yes I agree that in your case it doesn't seem to have been picked up.
> E.g.
>   https://sourceforge.net/p/gnuplot/git-main/ci/ef67fa09f12cd5f4cc869f7231d9e1f9b14c43a0/
> 
> your name shows in the associated ChangeLog entry but
> has not been propagated to the patchset itself.
> Same for the next 5 most ChangeLog entries with your name.
> 
> So it does seem that your name in particular is failing to trigger a
> match event in the annotation process. 

I'll run some traces.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.

Re: Trial git repo is back up

[Eric S. R. <es...@th...>]

Daniel J Sebald <dan...@ie...>:
> On 10/16/2017 01:17 PM, Eric S. Raymond wrote:
> >Trial git repo is back up, with the conversion bug I previously noted fixed.
> 
> Generally, cloning seems to take longer than I had expected, given gnuplot
> is a rather lean project.  It could be that SourceForge is just slow.  The
> cloning seems "chunky" in the respect it loads a bunch of objects then sort
> of slows down; speeds up again, slows down.

There's a pack command that helps with that - I forgot to use it.  I'll
do it on the next version; I've added it to the conversion script.

> I don't see any authorship mapping; everything seems to appear as the
> committer is the author.  For example, I've searched "git log" for "Sebald"
> and only see my name appear in ancillary comments.  Never is my name/address
> as gotten from the ChangeLog record in the authorship line.

That's...very odd.  I'll look into it.

> Some entries near the beginning of the project, as viewed through gitg:
> 
> # Apr 15 1998, 20:16 Initial import of beta340.
> 
> In gitg, no file diffs appear.

I see it too.  Some kind of fluky CVS artifact - probably of no
significance. A pretty common sort of glitch in older repos.

> # Apr 15 1998, 20:16 *** empty log message ***
> 
> In gitg, "Loading diff..." never resolves.

I see two commits that could match that.  They're both huge tree imports;
I'm not surprised your differ does a semi-infinite grind.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.

Re: Trial git repo is back up

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

On 10/16/2017 02:07 PM, Eric S. Raymond wrote:
> Daniel J Sebald <dan...@ie...>:
>> On 10/16/2017 01:17 PM, Eric S. Raymond wrote:
>>> Trial git repo is back up, with the conversion bug I previously noted fixed.
>>
>> Generally, cloning seems to take longer than I had expected, given gnuplot
>> is a rather lean project.  It could be that SourceForge is just slow.  The
>> cloning seems "chunky" in the respect it loads a bunch of objects then sort
>> of slows down; speeds up again, slows down.
> 
> There's a pack command that helps with that - I forgot to use it.  I'll
> do it on the next version; I've added it to the conversion script.
> 
>> I don't see any authorship mapping; everything seems to appear as the
>> committer is the author.  For example, I've searched "git log" for "Sebald"
>> and only see my name appear in ancillary comments.  Never is my name/address
>> as gotten from the ChangeLog record in the authorship line.
> 
> That's...very odd.  I'll look into it.
> 
>> Some entries near the beginning of the project, as viewed through gitg:
>>
>> # Apr 15 1998, 20:16 Initial import of beta340.
>>
>> In gitg, no file diffs appear.
> 
> I see it too.  Some kind of fluky CVS artifact - probably of no
> significance. A pretty common sort of glitch in older repos.

Yes, it's as though two entries were made for the same CVS checkin.  The 
above and next entries have the same time stamp.


>> # Apr 15 1998, 20:16 *** empty log message ***
>>
>> In gitg, "Loading diff..." never resolves.
> 
> I see two commits that could match that.  They're both huge tree imports;
> I'm not surprised your differ does a semi-infinite grind.

Oh, sure enough.  gitk has no problems with the repo and actually 
resolves diffs quite quickly compared to gitg, which often displayes 
"Loading diff..." for five seconds or more.  gitg project has switched 
to gtk3 recently, and it just isn't the same as it once was.  The older 
version was the best at displaying diffs and having a handy window for 
commit messages that one could edit while staging/de-staging individual 
hunks.  The new version now opens a *modal* commit message window, which 
is too cumbersome for efficient work.  It is "git gui" and "gitk" for 
me, for now.

Dan

Re: Trial git repo is back up

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

On 10/16/2017 01:59 PM, Ethan A Merritt wrote:
> On Monday, 16 October, 2017 13:42:30 Daniel J Sebald wrote:
>  > On 10/16/2017 01:17 PM, Eric S. Raymond wrote:
>  > > Trial git repo is back up, with the conversion bug I previously 
> noted fixed.
>  >
>  > Generally, cloning seems to take longer than I had expected, given
>  > gnuplot is a rather lean project. It could be that SourceForge is just
>  > slow. The cloning seems "chunky" in the respect it loads a bunch of
>  > objects then sort of slows down; speeds up again, slows down.
>  >
> 
>  > I don't see any authorship mapping; everything seems to appear as the
>  > committer is the author. For example, I've searched "git log" for
>  > "Sebald" and only see my name appear in ancillary comments. Never is my
>  > name/address as gotten from the ChangeLog record in the authorship line.
> 
> I see separate authorship attached to many of the commits,
> but yes I agree that in your case it doesn't seem to have been picked up.
> 
> E.g.
> 
> https://sourceforge.net/p/gnuplot/git-main/ci/ef67fa09f12cd5f4cc869f7231d9e1f9b14c43a0/
> 
> your name shows in the associated ChangeLog entry but
> has not been propagated to the patchset itself.
> Same for the next 5 most ChangeLog entries with your name.
> So it does seem that your name in particular is failing to trigger a
> match event in the annotation process.

There are probably more.  For example

<sfeam!2015-09-11T19:48:01+00:00Z> 2015-09-11 Akira Kakuto 
<ka...@fu...>

doesn't appear in the log either.

Dan

Re: Trial git repo is back up

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

On Monday, 16 October, 2017 14:27:09 Daniel J Sebald wrote:
> > your name shows in the associated ChangeLog entry but
> > has not been propagated to the patchset itself.
> > Same for the next 5 most ChangeLog entries with your name.
> > So it does seem that your name in particular is failing to trigger a
> > match event in the annotation process.
> 
> There are probably more.  For example
> 
> <sfeam!2015-09-11T19:48:01+00:00Z> 2015-09-11 Akira Kakuto 
> <ka...@fu...>
> 
> doesn't appear in the log either.
> 

Yeah. I only looked for your name in particular because you
raised the issue.

But you know what?  I don't think it matters that much, at least
for viewing through the SourceForge interface.  However it is that
you ended up with a commit identifier, once you click on it the
first thing shown is the ChangeLog entry with authorship
attribution.   

The mapping looks OK, it's only the label on the column marked
"author" that's misleading.   It should say "commited by".

	Ethan

Re: Trial git repo is back up

[Eric S. R. <es...@th...>]

Ethan A Merritt <sf...@us...>:
> Yeah. I only looked for your name in particular because you
> raised the issue.

It's good that he did. There's an actual bug; I'll chase it down after
I have slept.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.

Re: Trial git repo is back up

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

On 10/16/2017 02:48 PM, Ethan A Merritt wrote:
> On Monday, 16 October, 2017 14:27:09 Daniel J Sebald wrote:
> 
>  > > your name shows in the associated ChangeLog entry but
>  > > has not been propagated to the patchset itself.
>  > > Same for the next 5 most ChangeLog entries with your name.
>  > > So it does seem that your name in particular is failing to trigger a
>  > > match event in the annotation process.
>  >
>  > There are probably more.  For example
>  >
>  > <sfeam!2015-09-11T19:48:01+00:00Z> 2015-09-11 Akira Kakuto
>  > <ka...@fu...>
>  >
>  > doesn't appear in the log either.
>  >
> 
> Yeah. I only looked for your name in particular because you
> raised the issue.
> 
> But you know what? I don't think it matters that much, at least
> for viewing through the SourceForge interface. However it is that
> you ended up with a commit identifier, once you click on it the
> first thing shown is the ChangeLog entry with authorship
> attribution.

I'm fine with having the detailed ChangeLog entry there as the first 
diff.  But the main reasons for having the proper authorship in the 
changeset is for searching purposes, i.e.

git log | less

In less one can then search for changesets authored by whomever to get 
an idea of when something was done, etc.  We have the info, something

I'm even wondering if we could even replace the "empty log message" with 
some estimate of a message extracted from the corresponding ChangeLog 
entry.  But, there are only 210 such messages:

git log | grep "empty log message" | wc
     210    1050    6300

Maybe those could be replaced by hand (if at all), everyone doing five 
or ten summary lines, but it isn't that important.

Dan

Re: Trial git repo is back up

[Eric S. R. <es...@th...>]

Daniel J Sebald <dan...@ie...>:
> I'm even wondering if we could even replace the "empty log message" with
> some estimate of a message extracted from the corresponding ChangeLog entry.
> But, there are only 210 such messages:
> 
> git log | grep "empty log message" | wc
>     210    1050    6300
> 
> Maybe those could be replaced by hand (if at all), everyone doing five or
> ten summary lines, but it isn't that important.

A few of those are CVS artifacts that can be removed entirely.

But yes, I've done this sort of thing (filling in blank comments)
in the past.  In this case it should be oretty easy - use gitk to locate
the bad comment, look at the associated ChangeLog entry.

Everybody, feel free to send me proposed fill-ins; I'll add those
transformations to the conversion script.  It's easily done in
reposurgeon.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.

Re: Trial git repo is back up

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

On 10/16/2017 01:17 PM, Eric S. Raymond wrote:
> Trial git repo is back up, with the conversion bug I previously noted fixed.

Also, the branches are tags are not in the repository, at least not in 
the conventional way.  In neither git-gui, gitk nor gitg are there any 
branches listed other than "master" and "origin > master".  It could be 
there is some fragments of branches though.  In gitk I look at the 
visual, colored branches.  There are no bifurcations, but there are 
occasional colored lines appearing that then go away.  I suspect that 
those lines are supposed to be the branches.  I'm attaching a small 
portion of a screen shot illustrating how the line changes color rather 
than splitting out into branch.

My guess is that all the changeset info is there, but the labels that 
associate branch names with the SHAs are missing.

Dan

Re: Trial git repo is back up

[Eric S. R. <es...@th...>]

Daniel J Sebald <dan...@ie...>:
> On 10/16/2017 01:17 PM, Eric S. Raymond wrote:
> >Trial git repo is back up, with the conversion bug I previously noted fixed.
> 
> Also, the branches are tags are not in the repository, at least not in the
> conventional way.  In neither git-gui, gitk nor gitg are there any branches
> listed other than "master" and "origin > master".  It could be there is some
> fragments of branches though.  In gitk I look at the visual, colored
> branches.  There are no bifurcations, but there are occasional colored lines
> appearing that then go away.  I suspect that those lines are supposed to be
> the branches.  I'm attaching a small portion of a screen shot illustrating
> how the line changes color rather than splitting out into branch.
> 
> My guess is that all the changeset info is there, but the labels that
> associate branch names with the SHAs are missing.
> 
> Dan
> 

CVS branch labels turn into git lightweight tags. Look at the output
of git tag -l to check whether any tags actually got lost in the conversion.

The way gitk displays these (or doesn't) is confusing - I've never quite
understood its rules.  Adding the --tags option shows more of them.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.

Re: Trial git repo is back up

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

On 10/17/2017 06:01 AM, Eric S. Raymond wrote:
> Daniel J Sebald <dan...@ie...>:
>> On 10/16/2017 01:17 PM, Eric S. Raymond wrote:
>>> Trial git repo is back up, with the conversion bug I previously noted fixed.
>>
>> Also, the branches are tags are not in the repository, at least not in the
>> conventional way.  In neither git-gui, gitk nor gitg are there any branches
>> listed other than "master" and "origin > master".  It could be there is some
>> fragments of branches though.  In gitk I look at the visual, colored
>> branches.  There are no bifurcations, but there are occasional colored lines
>> appearing that then go away.  I suspect that those lines are supposed to be
>> the branches.  I'm attaching a small portion of a screen shot illustrating
>> how the line changes color rather than splitting out into branch.
>>
>> My guess is that all the changeset info is there, but the labels that
>> associate branch names with the SHAs are missing.
>>
>> Dan
>>
> 
> CVS branch labels turn into git lightweight tags. Look at the output
> of git tag -l to check whether any tags actually got lost in the conversion.

Tags rather than branches?  I think we'd prefer the CVS branches be 
mapped to git branches.


> The way gitk displays these (or doesn't) is confusing - I've never quite
> understood its rules.  Adding the --tags option shows more of them.

Yes, gitk takes the easy way out by displaying all the commits for a 
branch contiguously, then all the commits for the trunk or another 
branch.  Unlike most viewers, it doesn't seem to be able to display the 
commits chronologically and construct the trellis around that.  qgit is 
similar to gitk (probably using some of the same underlying tools as 
gitk).  So, although it displays things in a way that should be 
understandable, it doesn't really present a convenient view of the graph.

So, let me go back to gitg.  I've placed a screenshot of the test 
repository that was generated with cvsimport here:

http://www.dansebald.com/gnuplot/cvsimport_conversion_Screenshot_from_2017-10-17_11-52-18.png

That conversion has associated git branches with CVS branches, sort of 
what I was expecting.

Dan

Re: Trial git repo is back up

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

On Tuesday, 17 October 2017 07:01:45 Eric S. Raymond wrote:
> Daniel J Sebald <dan...@ie...>:
> > On 10/16/2017 01:17 PM, Eric S. Raymond wrote:
> > >Trial git repo is back up, with the conversion bug I previously noted fixed.
> > 
> > Also, the branches are tags are not in the repository, at least not in the
> > conventional way.  In neither git-gui, gitk nor gitg are there any branches
> > listed other than "master" and "origin > master".  It could be there is some
> > fragments of branches though.  In gitk I look at the visual, colored
> > branches.  There are no bifurcations, but there are occasional colored lines
> > appearing that then go away.  I suspect that those lines are supposed to be
> > the branches.  I'm attaching a small portion of a screen shot illustrating
> > how the line changes color rather than splitting out into branch.
> > 
> > My guess is that all the changeset info is there, but the labels that
> > associate branch names with the SHAs are missing.
> > 
> > Dan
> > 
> 
> CVS branch labels turn into git lightweight tags. Look at the output
> of git tag -l to check whether any tags actually got lost in the conversion.
> 
> The way gitk displays these (or doesn't) is confusing - I've never quite
> understood its rules.  Adding the --tags option shows more of them.

I'm not seeing any tags or branches at all. 

himeji [15] git pull
Already up-to-date.
himeji [16] git branch --list
* master
himeji [17] git tag --list
himeji [18] 


	Ethan

Re: Trial git repo is back up

[Eric S. R. <es...@th...>]

sfeam <sf...@us...>:
> I'm not seeing any tags or branches at all. 
> 
> himeji [15] git pull
> Already up-to-date.
> himeji [16] git branch --list
> * master
> himeji [17] git tag --list
> himeji [18] 

I see

esr@snark:/mnt/vault/esr-vault/gnuplot/gnuplot$ git tag --list
BETA_347_980925
BETA_347_981005
BETA_347_98101301
BETA_347_981121
BETA_348
BETA_348_981204
BETA_349
BETA_349_990114
GNUPLOT_19991210
GNUPLOT_20000330
GNUPLOT_37_20000507
GNUPLOT_990311
GNUPLOT_990312
GNUPLOT_990404
GNUPLOT_990507
GNUPLOT_990602
GNUPLOT_990612
GNUPLOT_990705
GNUPLOT_RELEASE_19991103
GNUPLOT_RELEASE_3_7_1
GNUPLOT_RELEASE_3_7_2
GNUPLOT_RELEASE_3_7_3
Release_4_2_1
Release_4_2_1-pre1
Release_4_2_3
Release_4_2_4
Release_4_2_5
Release_4_2_6
Release_4_4_0
Release_4_4_1
Release_4_4_2
Release_4_4_3
Release_4_4_4
Release_4_4_rc1
Release_4_6_0
Release_4_6_1
Release_4_6_2
Release_4_6_4
Release_4_6_5
Release_4_6_6
Release_4_6_rc1
Release_5_0_0
Release_5_0_1
Release_5_0_2
Release_5_0_3
Release_5_0_4
Release_5_0_5
Release_5_0_6
Release_5_0_7
Release_5_2_0
Release_5_2_1
axis-checkpoint-sourceforge-20000728
git-conversion
gnuplot-3-8f
gnuplot-4-4-alpha
gnuplot-4-6-alpha
gnuplot-5-0-rc2
gnuplot-5-2-rc0
pm3d-14
pre-lt-palette
pre-macport
pre-pm3d-02
pre-pm3d-11

I'll try adding a git push --tags to my conversion script.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.

Re: Trial git repo is back up

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

17. okt. 2017 09:01 "Eric S. Raymond" wrote:

I see

esr@snark:/mnt/vault/esr-vault/gnuplot/gnuplot$ git tag --list
BETA_347_980925
BETA_347_981005
BETA_347_98101301
BETA_347_981121
BETA_348
BETA_348_981204
BETA_349
BETA_349_990114
GNUPLOT_19991210
GNUPLOT_20000330
GNUPLOT_37_20000507
GNUPLOT_990311
GNUPLOT_990312
GNUPLOT_990404
GNUPLOT_990507
GNUPLOT_990602
GNUPLOT_990612
GNUPLOT_990705
GNUPLOT_RELEASE_19991103
GNUPLOT_RELEASE_3_7_1
GNUPLOT_RELEASE_3_7_2
GNUPLOT_RELEASE_3_7_3
Release_4_2_1
Release_4_2_1-pre1
Release_4_2_3
Release_4_2_4
Release_4_2_5
Release_4_2_6
Release_4_4_0
Release_4_4_1
Release_4_4_2
Release_4_4_3
Release_4_4_4
Release_4_4_rc1
Release_4_6_0
Release_4_6_1
Release_4_6_2
Release_4_6_4
Release_4_6_5
Release_4_6_6
Release_4_6_rc1
Release_5_0_0
Release_5_0_1
Release_5_0_2
Release_5_0_3
Release_5_0_4
Release_5_0_5
Release_5_0_6
Release_5_0_7
Release_5_2_0
Release_5_2_1
axis-checkpoint-sourceforge-20000728
git-conversion
gnuplot-3-8f
gnuplot-4-4-alpha
gnuplot-4-6-alpha
gnuplot-5-0-rc2
gnuplot-5-2-rc0
pm3d-14
pre-lt-palette
pre-macport
pre-pm3d-02
pre-pm3d-11


I would suggest unifying those names (perhaps to something like v5.2.rc0),
but that can be done later.

Mojca

Re: Trial git repo is back up

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

On Wednesday, 18 October 2017 02:12:51 Mojca Miklavec wrote:
> 17. okt. 2017 09:01 "Eric S. Raymond" wrote:
> 
> I see
> 
> esr@snark:/mnt/vault/esr-vault/gnuplot/gnuplot$ git tag --list
> BETA_347_980925
> BETA_347_981005
> BETA_347_98101301
> BETA_347_981121
> BETA_348
> BETA_348_981204
> BETA_349
> BETA_349_990114
> GNUPLOT_19991210
> GNUPLOT_20000330
> GNUPLOT_37_20000507
> GNUPLOT_990311
> GNUPLOT_990312
> GNUPLOT_990404
> GNUPLOT_990507
> GNUPLOT_990602
> GNUPLOT_990612
> GNUPLOT_990705
> GNUPLOT_RELEASE_19991103
> GNUPLOT_RELEASE_3_7_1
> GNUPLOT_RELEASE_3_7_2
> GNUPLOT_RELEASE_3_7_3
> Release_4_2_1
> Release_4_2_1-pre1
> Release_4_2_3
> Release_4_2_4
> Release_4_2_5
> Release_4_2_6
> Release_4_4_0
> Release_4_4_1
> Release_4_4_2
> Release_4_4_3
> Release_4_4_4
> Release_4_4_rc1
> Release_4_6_0
> Release_4_6_1
> Release_4_6_2
> Release_4_6_4
> Release_4_6_5
> Release_4_6_6
> Release_4_6_rc1
> Release_5_0_0
> Release_5_0_1
> Release_5_0_2
> Release_5_0_3
> Release_5_0_4
> Release_5_0_5
> Release_5_0_6
> Release_5_0_7
> Release_5_2_0
> Release_5_2_1
> axis-checkpoint-sourceforge-20000728
> git-conversion
> gnuplot-3-8f
> gnuplot-4-4-alpha
> gnuplot-4-6-alpha
> gnuplot-5-0-rc2
> gnuplot-5-2-rc0
> pm3d-14
> pre-lt-palette
> pre-macport
> pre-pm3d-02
> pre-pm3d-11
> 
> 
> I would suggest unifying those names (perhaps to something like v5.2.rc0),
> but that can be done later.

???
Sorry, I don't get it.
Why would you want to unify any of those?
What I want is to be able to check them out separately.

Everything labeled pre* or BETA* can be junked, but that is
not what I understand as "unify".

Now maybe I just misunderstand the whole git thing.
Remember I'm new to this and thinking in terms of CVS.
What I'm thinking is that if I do 
 git checkout Release_5_0_7

I'll get the same files that were in the release tarball
gnuplot-5.0.7.tar.gz
And if for some reason we wanted to continue development of the 5.0 series
for a release 5.0.8, I could clone it (I don't know what git command that is)
as a new branch Release_5_0_8 and push that one back to the repository.
Have I got that wrong?

	Ethan

Re: Trial git repo is back up

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

On 10/17/2017 08:05 PM, sfeam wrote:
> On Wednesday, 18 October 2017 02:12:51 Mojca Miklavec wrote:
>> 17. okt. 2017 09:01 "Eric S. Raymond" wrote:
>>
>> I see
>>
>> esr@snark:/mnt/vault/esr-vault/gnuplot/gnuplot$ git tag --list
>> BETA_347_980925
>> BETA_347_981005
>> BETA_347_98101301
>> BETA_347_981121
>> BETA_348
>> BETA_348_981204
>> BETA_349
>> BETA_349_990114
>> GNUPLOT_19991210
>> GNUPLOT_20000330
>> GNUPLOT_37_20000507
>> GNUPLOT_990311
>> GNUPLOT_990312
>> GNUPLOT_990404
>> GNUPLOT_990507
>> GNUPLOT_990602
>> GNUPLOT_990612
>> GNUPLOT_990705
>> GNUPLOT_RELEASE_19991103
>> GNUPLOT_RELEASE_3_7_1
>> GNUPLOT_RELEASE_3_7_2
>> GNUPLOT_RELEASE_3_7_3
>> Release_4_2_1
>> Release_4_2_1-pre1
>> Release_4_2_3
>> Release_4_2_4
>> Release_4_2_5
>> Release_4_2_6
>> Release_4_4_0
>> Release_4_4_1
>> Release_4_4_2
>> Release_4_4_3
>> Release_4_4_4
>> Release_4_4_rc1
>> Release_4_6_0
>> Release_4_6_1
>> Release_4_6_2
>> Release_4_6_4
>> Release_4_6_5
>> Release_4_6_6
>> Release_4_6_rc1
>> Release_5_0_0
>> Release_5_0_1
>> Release_5_0_2
>> Release_5_0_3
>> Release_5_0_4
>> Release_5_0_5
>> Release_5_0_6
>> Release_5_0_7
>> Release_5_2_0
>> Release_5_2_1
>> axis-checkpoint-sourceforge-20000728
>> git-conversion
>> gnuplot-3-8f
>> gnuplot-4-4-alpha
>> gnuplot-4-6-alpha
>> gnuplot-5-0-rc2
>> gnuplot-5-2-rc0
>> pm3d-14
>> pre-lt-palette
>> pre-macport
>> pre-pm3d-02
>> pre-pm3d-11
>>
>>
>> I would suggest unifying those names (perhaps to something like v5.2.rc0),
>> but that can be done later.
> 
> ???
> Sorry, I don't get it.
> Why would you want to unify any of those?
> What I want is to be able to check them out separately.
> 
> Everything labeled pre* or BETA* can be junked, but that is
> not what I understand as "unify".

I would think the tag names matching the tarball file name makes sense. 
In any case, this cleanup and naming convention can be dealt with later 
by Ethan, et al. as they gradually become comfortable with the commands 
of git.  These details are best dealt with once we have an actual 
canonical repository.  Think about it for now.

Eric's concern should be more the things that can be automated in a 
script or whatnot.


> Now maybe I just misunderstand the whole git thing.
> Remember I'm new to this and thinking in terms of CVS.
> What I'm thinking is that if I do
>   git checkout Release_5_0_7
> 
> I'll get the same files that were in the release tarball
> gnuplot-5.0.7.tar.gz

Generally you've got the right idea.


> And if for some reason we wanted to continue development of the 5.0 series
> for a release 5.0.8, I could clone it (I don't know what git command that is)
> as a new branch Release_5_0_8 and push that one back to the repository.
> Have I got that wrong?

The terminology "clone" only applies to the whole repository.  One 
clones the repository at the start, which brings everything onto their 
local computer; all changesets, hence all branches and all tags.  Except 
for the push/pull associated with development to keep local and "origin" 
repositories in sync, the local and origin repository look exactly the 
same.  That's why the word "clone" is used.  This is what it means to be 
a "distributed" source control system.  Every user has the whole 
history, not just some lone repository on a remote server.

Just use "checkout", it works for branches, for tags, time stamps, file 
names (if one wants to toss file modifications).  "checkout" is sort of 
the workhorse command of git.

I suspect doing

git checkout Release_5_0_7

checks out the "branch-5-0-stable" branch (or, I should say the pathway 
for which the head is "branch-5-0-stable") at the snapshot for the time 
associated with the tag.

Right now, the in-progress repository doesn't have branches.  We have to 
retain the branch structure from CVS, otherwise we are stuck as far as 
patching/back-porting fixes in recent versions.  For example, see the 
graph in the gitg GUI I posted here:

http://www.dansebald.com/gnuplot/cvsimport_conversion_Screenshot_from_2017-10-17_11-52-18.png

which has branch-4-0-stable, branch-4-2-stable, etc.  We want the 
in-progress repository looking like that.

Dan

Re: Trial git repo is back up

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

17. okt. 2017 18:06 steam wrote:

On Wednesday, 18 October 2017 02:12:51 Mojca Miklavec wrote:
> 17. okt. 2017 09:01 "Eric S. Raymond" wrote:

> I would suggest unifying those names (perhaps to something like v5.2.rc0),
> but that can be done later.

???
Sorry, I don't get it.
Why would you want to unify any of those?


Why would you want version 3.7.1 to be called GNUPLOT_RELEASE_3_7_1 and
version 5.2.1 to be called Release_5_2_1? Why not use something following
the same pattern for both? Like a simple v3.7.1/v5.2.1?

What I want is to be able to check them out separately.


Sure, changing the name won't disable it, but unless you unify names,
you'll have to check the exact name for each revision you'll want to
checkout.

Everything labeled pre* or BETA* can be junked, but that is
not what I understand as "unify".

Now maybe I just misunderstand the whole git thing.
Remember I'm new to this and thinking in terms of CVS.
What I'm thinking is that if I do
 git checkout Release_5_0_7

I'll get the same files that were in the release tarball
gnuplot-5.0.7.tar.gz


No, you won't because the generated files (configure etc) are missing. On
Github one can attach files to tags though.

And if for some reason we wanted to continue development of the 5.0 series
for a release 5.0.8, I could clone it (I don't know what git command that
is)
as a new branch Release_5_0_8 and push that one back to the repository.
Have I got that wrong?


You would checkout the branch 5.0, make changes to it and then tag a new
release. You would never make a 5.0.8 branch, only a tag.

Mojca

Re: Trial git repo is back up

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

On Wednesday, 18 October 2017 07:56:45 you wrote:
> 17. okt. 2017 18:06 steam wrote:
> 
> On Wednesday, 18 October 2017 02:12:51 Mojca Miklavec wrote:
> > 17. okt. 2017 09:01 "Eric S. Raymond" wrote:
> 
> > I would suggest unifying those names (perhaps to something like v5.2.rc0),
> > but that can be done later.
> 
> ???
> Sorry, I don't get it.
> Why would you want to unify any of those?
> 
> 
> Why would you want version 3.7.1 to be called GNUPLOT_RELEASE_3_7_1 and
> version 5.2.1 to be called Release_5_2_1? Why not use something following
> the same pattern for both? Like a simple v3.7.1/v5.2.1?

Ah. I understand now.
Rename them according to a unified scheme of names.
Yes, that would make sense.

I was confused about the reset of it.   I realize now that all
of the names listed were tag names, not separate branches.
The list of branches would be much shorter, the important
ones being the current development branch and the
current stable branch.

Sorry for the noise.

	Ethan


> What I want is to be able to check them out separately.
> 
> 
> Sure, changing the name won't disable it, but unless you unify names,
> you'll have to check the exact name for each revision you'll want to
> checkout.
> 
> Everything labeled pre* or BETA* can be junked, but that is
> not what I understand as "unify".
> 
> Now maybe I just misunderstand the whole git thing.
> Remember I'm new to this and thinking in terms of CVS.
> What I'm thinking is that if I do
>  git checkout Release_5_0_7
> 
> I'll get the same files that were in the release tarball
> gnuplot-5.0.7.tar.gz
> 
> 
> No, you won't because the generated files (configure etc) are missing. On
> Github one can attach files to tags though.
> 
> And if for some reason we wanted to continue development of the 5.0 series
> for a release 5.0.8, I could clone it (I don't know what git command that
> is)
> as a new branch Release_5_0_8 and push that one back to the repository.
> Have I got that wrong?
> 
> 
> You would checkout the branch 5.0, make changes to it and then tag a new
> release. You would never make a 5.0.8 branch, only a tag.
> 
> Mojca