gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] Updating my git work-in-progess branch?


From: ng0
Subject: Re: [GNUnet-developers] Updating my git work-in-progess branch?
Date: Fri, 15 Mar 2019 19:17:23 +0000

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 <address@hidden> 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" <address@hidden> wrote:
> > 
> >>> On 15. Mar 2019, at 09:45, Hartmut Goebel
> >>> <address@hidden> 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          |
> >>> address@hidden               | |
> >>> www.crazy-compilers.com | compilers which you thought are
> >>> impossible |
> >>> 
> >>> 
> >>> _______________________________________________
> >>> GNUnet-developers mailing list
> >>> address@hidden
> >>> https://lists.gnu.org/mailman/listinfo/gnunet-developers
> >> 
> > 
> > 
> > _______________________________________________
> > GNUnet-developers mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/gnunet-developers
> 



> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnunet-developers




reply via email to

[Prev in Thread] Current Thread [Next in Thread]