[Top][All Lists]

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

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

From: Corvus Corax
Subject: Re: [GNUnet-developers] Updating my git work-in-progess branch?
Date: Fri, 15 Mar 2019 17:06:14 +0100

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
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.



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 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               | |
> > | compilers which you thought are
> > impossible |
> > 
> > 
> > _______________________________________________
> > GNUnet-developers mailing list
> > address@hidden
> >  

reply via email to

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