gnuplot-beta

Some general comments about git repository and commit policy

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

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.

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

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

Re: Some general comments about git repository and commit policy

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

On 10/13/2017 05:20 PM, Ethan A Merritt wrote:
> 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

You may create branches anywhere in the repository.  The first step 
would be to checkout the 5.2 branch with

git checkout branch-5-2-stable

with the requirement that there be no modified files or staged modified 
files.  (Plain "git checkout FILENAME" will discard file changes and 
return the file to the repository.)

Now once in branch-5-2-stable, do a branch

git checkout -b b52_patch

and any modifications and changesets one makes at that point end up on 
"branch"/"head" b52_patch.  I've done the above in the test repository, 
and inquiring the branch info tells me:

sebald@ ~/gnuplot/test_repository/gnuplot $ git branch
* b52_patch
   branch-5-2-stable
   master

I think what the above is telling us is b52_patch is the current active 
branch, branch-5-2-stable was the prior branch, and prior to that was 
master.  If one does a "merge" from within b52_patch, I believe git 
assumes the prior branch "branch-5-2-stable" is to be the merge point. 
However, one can merge anywhere, I think, just by specifying an object 
(tag, head name, probably SHA number or however many first X unique 
numbers).

Dan