The impression I get from reading the docs and the post you linked Alan, is
that there is a tendency for people coming from svn to forget that git is a
distributed vcs. Perhaps some of these branches would be more at home in the
various developers own repositories. I cloned the repository today and already
generated two branches - partly to see how it works, but partly because it is
so useful to be able to do so.
That said, if for example you clone the repository now and continue to develop
the cmake_test branch, but that branch gets deleted from the SF repository,
does that make it really painful to merge it back in? I have a feeling the
answer might be yes but I'm not sure.
Maybe aim should be that any "live" branches should be merged into the master
branch when possible (i.e. when the work in them is ready to merge back in), at
which point they can be safely deleted. Then when they are needed in the future
a developer creates their own local branches to do the same job. Of course
these local repositories can be on github for collaborative purposes. To be
honest it is so easy to create a branch that I have a feeling that you won't
want a cmake_test branch, but instead you will create different branches for
each test you do and then either discard them or merge them back in. I'm
already thinking I will create a branch for working through removing exit()
calls which I will regularly merge back in to my master and another branch for
adding wxGCDC support which will itself branch to do specific smaller tasks
then merge back to the wxGCDC branch, which will hopefully merge back into my
master eventually.
As far as dead branches are concerned - if they really are dead then there is
presumably no reason to keep them, but I don't think it is useful to delete
branches that we might want in the future. All that will happen is that instead
of git holding a pointer to the branch head, one of us will end up with a text
file containing the sha of the heads so we can find them again easily.
Basically, I'm tending towards Alan's view of not deleting branches, but with
the caveat that only if they have not been merged into master and they might be
of some use at a later date. If they have been merged or they are of no use
then they should be deleted. Of coarse none of these branches are mine, and I'm
a newbie to git, so feel free to ignore me completely :-)
Phil
________________________________
From: Alan W. Irwin <ir...@beluga.phys.uvic.ca>
To: Hazen Babcock <hbabc...@mac.com>
Cc: Plplot-devel mailing list <plplot-devel@lists.sourceforge.net>
Sent: Wednesday, 13 August 2014, 20:16
Subject: Re: [Plplot-devel] Fwd: Re: [Plplot-core] git conversion status
On 2014-08-13 10:28-0400 Hazen Babcock wrote:
>
> Sending this to a wider audience. In short, PLplot is now using git for
> version control.
>
> http://sourceforge.net/p/plplot/plplot/ci/master/tree/
>
> -Hazen
>
> -------- Original Message --------
> Subject: Re: [Plplot-core] git conversion status
> Date: Tue, 12 Aug 2014 16:24:27 -0400
> From: Hazen Babcock <hbabc...@mac.com>
> To: plplot-c...@lists.sourceforge.net
>
> On 8/11/2014 6:47 PM, Hazen Babcock wrote:
>>
>> If there are no additional commits between today and tomorrow I'll clone
>> this to SF and change the SVN repo to read-only.
>
> All set now. Our SVN repository is (or should be) read-only under the
> "Old Code" tab. Our new git repository is available under the "Code" tab.
>
> Two initial suggestions:
> 1. Like github, SF is displaying the README.txt file. This appears to
> have last been modified in 2007. Maybe this should be the same as
> README.release? Or maybe it should be updated?
>
> 2. Clean up the repository by pruning off all the branches. Don't worry
> they'll still be there if you really want to look at them (as described
> here):
>
> http://stackoverflow.com/questions/3640764/can-i-recover-branch-after-the-deletion-in-git
>
> Many projects that I have seen only have a master branch in their
> release repository.
Many thanks, Hazen, for pushing this conversion project to completion.
> [Suggestions] 2. Clean up the repository by pruning off all the
branches. Don't worry
> they'll still be there.
>>From my very recent first read of the Chapter on branching in "Pro
Git" (<http://git-scm.com/book> and highly recommended), it appears git
branches are extremely light-weight and simply point to a particular
snapshot in the repository, and that chapter also confirms what you
said about removing a branch does not remove the snapshot.
> if you really want to look at them (as described
> here):
>
>
http://stackoverflow.com/questions/3640764/can-i-recover-branch-after-the-deletion-in-git
That method does not seem fool-proof. See the expire subcommand for "git
reflog". Furthermore, some of the PLplot branches are still active
(e.g., test_cmake) and useful even though I will likely never want to
merge that material to the master branch.
So I would prefer branches not be deleted if they are active
(test_cmake and perhaps others), and for the ones we decide to delete,
I would like some permanent record of the branch that would allow us
to reliably resurrect it again. My impression is you cannot delete
tags. If that is true, could we make a specially named tag, e.g.,
branch_AM-LT for the tip of the currently existing AM-LT branch before
deleting that branch? And then afterward be able to reliably
resurrect the branch using that tag to access the last commit
corresponding to the (old, deleted) branch head?
And so on for the other branches we wish to delete?
(Sorry that questions about policy for our git repo keep getting
conflated with questions about git capabilities, but we are likely
to be stuck with such conflation for quite a while until more of
us become git experts.)
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
------------------------------------------------------------------------------
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
------------------------------------------------------------------------------
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
