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
