Re: Some general comments about git repository and commit policy

[Ethan A M. <merritt@u.washington.edu>]

On Friday, 13 October, 2017 16:44:59 Daniel J Sebald wrote:
> Ethan mentioned offline old CVS branches, that brings to mind something 
> about git worth mentioning for those maintainers not familiar with git. 
> git uses terminology "branch" quite often, but after working with git 
> for a while one will realize the "branch" analogy fails a bit after 
> merges are done.  More accurately, git pushes the heads along.  It's 
> important noting this because once two branch heads are merged, the 
> names once associated with those branches are lost and one doesn't know 
> what branch was what at the time they were under development.

So post-conversion, what is the git terminology that distinguishes
the stable 5.2 branch from the main 5.3 branch?

If I want to apply a patch specifically to the 5.2 "branch"
(clone something / modify it / merge back)
what are the git commands I use to do that so that it doesn't 
affect the main development "branch"?

	Ethan



> 
> For example, say I create a branch from "master" called "sebald001" with
> 
> git checkout -b sebald001
> 
> I then make some commits on "sebald001", while on "master" some other 
> commits are made by others.  If the two are merged, it's not obvious 
> what changes were done at the time on "sebald001" versus those that were 
> done at the time on "master".
> 
> The reason this is important is because often git projects have a rule 
> of no modifications on the "master" branch, only merges.  So, even the 
> smallest of mods are done as a branch and then merged.  Whether you want 
> to do that here, where there are a lot of people submitting changesets 
> and patch sets is worth discussion.  I believe that any submitted 
> changesets can be rebased locally by the maintainers to fit any model 
> you decide upon and then pushed to the main repository.
> 
> In any case, there are some logistical and procedural things the 
> maintainers will have to decide on.  I just want to point out that 
> although git gives a ton of flexibility in terms of merging branches it 
> can be real confusing after the fact to know exactly how things 
> progressed when there are intertwined multiple merged branches.
> 
> Dan
> 
> ------------------------------------------------------------------------------
> 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

-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742