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