Re: Historic and proposed future use of branches in the findutils repository

[Bernhard Voelker]

On 01/05/2016 11:25 PM, James Youngman wrote:
> 2) Proposed arrangement for the future
> 
> a) Future of "master": continue to use it for development, but also
> cut "stable" releases directly from here.   Abandon the use of
> "stable" branches.  Instead, develop on master and cut stable releases
> from there, directly.   Expect committers to do any destabilizing work
> mostly on private topic branches, though with the option of creating
> shared topic branches (in the Savannah repository) for any large
> destabilizing projects needing collaboration.
> 
> b) rel-4-6-fixes : stop using this as a (current) stable release
> branch ... in other words, discontinue the use of this, merge it into
> master, or obsolete it by creating a 4.8.x release on master.
> 
> c) other rel-xxxx-fixes branches: keep these for historical record.
> 
> d) The other branches could be deleted from the Savannah git
> repository since they're no longer used and are simply confusing.
> Prior to deleting these we could ask the FSF to somehow archive the
> existing (pre-branch-deletion) git repository.  (better ideas
> welcome).
> 
> I believe that this proposal matches the preferences of the downstream
> maintainers (in so far as they each have a preference).  I believe
> this arrangement is also easier for committers due to the lack of a
> need to cherry-pick changes onto a "stable" release branch.
> 
> Thoughts, improvements, suggestions, feedback?

+1

To summarize:
* only commit on one development line - the master branch,
* cut future releases directly from there,
* maybe or not keep historic branches as they are (they do no harm).

I think you cannot remove a branch and keep the history, because a
branch is only a dynamic pointer to a commit in Git.  These unreferenced
commits would stay in the repository until one runs "git gc" there.
If you mind the old branch names in the "git branch -r" output, then
we could also create a tag with the same name there, and remove the
branch, but then the old names would clutter the tag list, well ...
Regarding archiving: each "git clone" is a perfect archive AFAIK. ;-)

I'd personally only remove the rel-4-6-fixes branch, as it is not and
never has been of much use and is confusing for recent "history" - well,
the past 2-3 weeks; all relevant commits seem to exist on master
already:

  diff -u0 \
    <(git log --oneline v4.6.0..rel-4-6-fixes | cut -d' ' -f2- | sort) \
    <(git log --oneline v4.6.0..master        | cut -d' ' -f2- | sort) \
    | grep '^-'
  --- /dev/fd/63  2016-01-06 21:13:23.850263546 +0100
  -Ensure the version number in NEWS matches configure.ac
  -Make regexprops.texi, regeprops.c, and 'make update-copyright' consistent.
  -Merge branch 'rel-4-6-fixes' of ssh://git.sv.gnu.org/srv/git/findutils into 
rel-4-6-fixes

After a "git push origin :rel-4-6-fixes" to remove the remote branch,
maybe someone could run "git gc" on the server to remove the 21 then-
unreferenced commits.

Thanks & have a nice day,
Berny