On Tue, 05 Jun 2012 01:13:05 -0700, Marcin Cieslak <saper(a)saper.info>
Bergi <a.d.bergi(a)web.de> wrote:
Doesn't Git encourage us to create as many branches as we can, to share
our work and collaborate? Or should I publish my branch(es) somewhere
else, maybe without gerrit at all?
Sorry to say this and many people here might
Forget 80% of git versatility when working with gerrit. No "git merge"
(other than fast forward), no "git cherry-pick" (only -n) and branches
are rarely useful for more than a local marker for commit.
You are supposed to push one perfect commit for review; you might
also push some with dependencies between them but then things get
On Thu, 07 Jun 2012 01:11:51 -0700, Brion Vibber <brion(a)pobox.com> wrote:
On Wed, Jun 6, 2012 at 1:45 AM, Bergi
But I thought there was a possibility to push to
our repository without
using Gerrit / being affected by Gerrit at all?
I can understand that Gerrit is a nice review tool which is useful for
production and master branches, but I'd like to have a repo for
& sharing cool new features without any review at all. The discussion
happen at bugzilla or mediawiki.org
Do you think there is a way?
Until we get things more nicely sorted out, feel free to maintain
development repositories on hosted git services such as:
One of the great benefits of git is that you're *not* forced to always
the same server. You can work on code anywhere you like, share it
you like, with anyone you like, and then rebase/flatten and submit up to
gerrit when your code is ready.
I think I should clear something up / remind people about git.
Firstly, remember there are two types of branches, heck in a way there are
three. Branches in your private repo you never push out as actual branches
themselves. Branches that you do push out publicly to work on with other
people. And branches like our REL#_## branches that are meant to be used
Even with whether or not you can push a branch somewhere put aside one
thing git is encouraging you to do is create a branch every time you start
working on something. Even if you never push it anywhere and you merge it
away, squash it, whatever... Git encourages you to branch things so you
can easily stop and work on something else in the same project without
having to actually destroy what you were working on, deal with explicit
`svn commit thisfile, thatfile, andthatfile` and changes being in the same
file, having to revert what you were working on just to start something
else, or maintain multiple copies of the same repo.
Secondly, Git does NOT encourage you to commit branches into some central
repository to share them with other people. ...that's very non-git.
Frankly that's very svn.
Git encourages you to work with 4 types of copies of the same repo from
- There is a central repository, or maybe multiple of them. eg: Some group
of maintainers or maybe something like gerrit is in charge of putting
commits into these repos. And everyone pulls final trusted commits from
these repos. No unchecked commit goes in here. That includes branches. You
never tell a maintainer to put your unfinished half-baked branch into
- Then you have a single private repository on your computer. You pull
other peoples commits into this. Work on code. Make commits. And push
- Then you have a single public repository of your own available on the
web. Whenever you make changes you want to publish you push them here. If
you want something in the central repositories, you push it to your public
repo and then you ask a maintainer to pull it, review it, and then push it
into the central repo.
- Then there are multiple public repos for other contributors to the
project. Some on GitHub, some on Gitorious, some on some other host, some
on people's own private repos, and maybe the project itself will have some
place to host your personal repos. When someone has something you are
interested in that has not made it into a central repo yet, you pull it
from that person's public repo.
So Git does not encourage you to put half-baked code into any of the
maintained repos. Git encourages you to branch your code. Push a
collaborative project into your own personal public repo. Talk about it
with other people. Have them pull the project from your public repo. When
they make an improvement they push it to their public repo. And then you
pull what they did into yours and combine it with your improvements. Then
when your small group of people are done collaborating on this sub-project
one of you make a pull request to one of the maintainers and has them
merge it into the central repository.
So Gerrit isn't really directly lacking something here. GitHub, Gitorious,
etc... aren't workarounds for collaborating on some sub-project improving
MediaWiki. They are actually the git-way of doing this collaboration.
The problem with Gerrit here is indirect. It's encouraging people to do
away with their own public repository to parade new things around with.
That said. This does make me think that treating branches in my own
code-review idea (Gareth) like commits for review. Anyone gets to submit a
potential branch for review, just like a commit, and then someone with
accept permissions (+2) and permissions in that branch (eg: if rights are
restricted for certain patterns) gets to accept that request resulting in
the merge/creation of that branch. (or maybe they are actually one and the
same thing, commits for review can go into any branch, including ones that
don't exist, then when accepted a branch is created). Simply since there
is additionally value in some types of sub-projects that everyone is
involved in and go through the normal pattern of review (eg: The partial
rewrite of a project resulting in 2.0.0).
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name