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