Schanzenbach, Martin transcribed 6.2K bytes: > I think this is a good idea. We should decide on and document branch naming > and conventions. Then regularly (e.g. when releasing) do housekeeping. > Further, access control rights could be handled more lax then for branches > and for the 1-3 "main" branches we have stronger protection mechanisms.
I for one would prefer not to be one of the few people to be pinged about branch deletion (which now requires a couple of steps, temporarily being the deladmin and then revoking the rights again, or something I've never documented for myself and need to read up every time I do it. Which happens rarely.) > The latter was just never really an issue because > > 1. open contribution ist not possible > 2. developers which can contribute are just "trusted" with master as well > 3. Pretty much everything is done directly in master instead of > issue->branch->work->rebase&merge which is what _should_ happen > > If our developer base grows significantly, then I can see this becoming an > issue. Definitely. > So, maybe we extract the proposal below into a bugreport where we can discuss > it more and then implement respective changes. Sounds good. Since we require the CAA I guess looking into a "mob branch" as some call an open-for-all branch is a no-go. I looked into this briefly in the past with my own gitolite site installation and didn't make much progress so far. > > On 15. Mar 2019, at 17:06, Corvus Corax <[email protected]> wrote: > > > > > > If I may add a suggestion. > > > > On some other projects I worked on, we used relatively strict > > namespacing rules. Branches pushed to the repo should have the name > > > > <developername>/<branchname> (with further subdirectories possible > > depending on whatever the developer considered apropriate. often in the > > form of > > <developername>/ISSUE-<number>-<branch-description> > > but that wasn't enforced > > > > that way, even though we had hundreds of branches, it was still > > relatively easy to look at the relevant ones and find one's own. > > > > Only maintainers had the ability to merge into "master" or > > "next" ("master" was always frozen between releases, so we merged into > > "next" for new features to be tested until the next release cycle, > > while developers would regularly merge "next" back into their dev > > branches or rebase into a new branch to stay up to date) > > > > only "master" and "next" were specially protected by gitolite, while > > developers were allowed to force-push to branches within their own > > namespace, but we also had roughly-yearly git cleanup rounds where > > every developer had to name the branches they were still using or > > working on, and old stuff was removed > > > > branches were code reviewed before merging them to "next", not unlike > > pull requests on github. only release-maintainers could push to master, > > while next was more open, but never allowed force-pushes. > > > > cheers > > > > CorvusCorax > > > > > > On Fri, 15 Mar 2019 11:19:09 +0100 > > "Schanzenbach, Martin" <[email protected]> wrote: > > > >>> On 15. Mar 2019, at 09:45, Hartmut Goebel > >>> <[email protected]> wrote: > >>> > >>> > >>> Am 15.03.19 um 09:19 schrieb Christian Grothoff: > >>>> Force pushes are never allowed, you must always rebase. > >>> > >>> Rebase also requiers a force push since the branch is not > >>> continuing the prior history. > >>> > >>> I'm used to provide a series of patches for review, fix and clean > >>> up, them merge or rebase. So for review I need to use an external > >>> repo, e.g. at gitlab.digitalcourage.de. Not much of a problem for > >>> me, but this hinders the reviewers workflow. > >>> > >> > >> I don't understand your problem. You can use another git repo as a > >> mirror and work there if you want. It should just be another remote > >> after all. You simply do: > >> > >> $ git checkout -b <mybranch> > >> Do work > >> $ git rebase master > >> $ git checkout master > >> $ git merge <mybranch> > >> $ git push > >> > >> I do not see where you'd need to force push at any point. > >> > >>> > >>>> AFAIK only admins can delete branches that have been pushed to the > >>>> server. > >>> > >>> So after merging a branch I need to ask an admins to remove the old > >>> branch? Is this a Arbeitsbeschaffungsmaßname? > >> > >> Hopefully we will have a gitlab setup at some point that allows us to > >> deal with this using user namespaces and pull requests. Anyway, > >> deleting branches is not really necessary, but I agree that it will > >> clutter the main server remote unless we have such a setup. > >> > >>> > >>> -- > >>> Regards > >>> Hartmut Goebel > >>> > >>> | Hartmut Goebel | > >>> [email protected] | | > >>> www.crazy-compilers.com | compilers which you thought are > >>> impossible | > >>> > >>> > >>> _______________________________________________ > >>> GNUnet-developers mailing list > >>> [email protected] > >>> https://lists.gnu.org/mailman/listinfo/gnunet-developers > >> > > > > > > _______________________________________________ > > GNUnet-developers mailing list > > [email protected] > > https://lists.gnu.org/mailman/listinfo/gnunet-developers > > _______________________________________________ > GNUnet-developers mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/gnunet-developers _______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
