public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: hasufell <hasufell@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Developer branches on proj/gentoo
Date: Tue, 11 Aug 2015 16:12:29 +0200	[thread overview]
Message-ID: <55CA02CD.9050309@gentoo.org> (raw)
In-Reply-To: <20150811135216.GG21010@sigkill.axestech.net>

On 08/11/2015 03:52 PM, Patrice Clement wrote:
> Hi there
> 
> According to https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Branching_Model,
> "there may be developer-specific, task-specific, project-specific branches
> etc". As far as I understand, it means I can go and create my own branch on the
> main repository and push it and it gets spread all over the place. Is that
> correct?
> 
> Could someone explain to me the rationale behind this decision?
> 
> Truth to be told, I kinda dislike the fact any developer can do this. 
> 
> proj/gentoo should be kept for "serious business" i.e. commits that affects the
> tree. On the long run, if everybody goes down that road, we will see flourish
> numerous branches (who said unmaintained?), all stalled at a different state of
> the main repo, and it will only generate a lot of noise and confusion for
> nothing. Further, since we've moved over to git, the main tree now gets
> replicated to github and we all have github accounts here, don't we? Which makes
> the whole forking and submitting PRs a cinch.
> 
> If a developer wants to tinker with the tree, he can fork it to its github
> devspace, fiddle around, and later on send us a PR back with his changes to
> merge.
> 

Branches can still make sense, even if the model is that everyone has
his own fork, see
http://nvie.com/posts/a-successful-git-branching-model/
for an example.

I currently don't see a reason to limit the workflow to one master branch.

It doesn't necessarily generate noise or confusion and there are various
ways to only fetch specific branches if you really need to do so. Git's
main advantage _are_ branches and it has sufficient methods to deal with
a lot of them.

If they cause trouble, we can still prune them and enforce stricter
rules, but since we don't even know how they will be used, this point is
moot yet.


  parent reply	other threads:[~2015-08-11 14:12 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-11 13:52 [gentoo-dev] Developer branches on proj/gentoo Patrice Clement
2015-08-11 14:01 ` Michał Górny
2015-08-11 14:09   ` Tobias Klausmann
2015-08-11 14:10   ` Alexis Ballier
2015-08-11 14:19     ` hasufell
2015-08-11 14:26       ` Anthony G. Basile
2015-08-11 15:02         ` Rich Freeman
2015-08-11 15:05         ` Alexis Ballier
2015-08-11 15:01       ` Alexis Ballier
2015-08-11 15:11   ` Ian Stakenvicius
2015-08-11 15:21     ` Alexis Ballier
2015-08-11 15:51       ` Ian Stakenvicius
2015-08-11 18:47         ` Alexis Ballier
2015-08-11 16:03       ` hasufell
2015-08-11 16:08         ` Ian Stakenvicius
2015-08-11 18:53         ` Alexis Ballier
2015-08-11 14:12 ` hasufell [this message]
2015-08-11 14:24   ` William Hubbs

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55CA02CD.9050309@gentoo.org \
    --to=hasufell@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox