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

[Schanzenbach, Martin]

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

So, maybe we extract the proposal below into a bugreport where we can discuss 
it more and then implement respective changes.

> 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

signature.asc
Description: Message signed with OpenPGP