Received: by 10.180.83.74 with SMTP id o10mr1735842wiy.1.1337068091400;
        Tue, 15 May 2012 00:48:11 -0700 (PDT)
X-BeenThere: scala-ide-dev@googlegroups.com
Received: by 10.180.75.78 with SMTP id a14ls607552wiw.4.gmail; Tue, 15 May
 2012 00:48:10 -0700 (PDT)
Received: by 10.180.14.69 with SMTP id n5mr1494107wic.4.1337068090624;
        Tue, 15 May 2012 00:48:10 -0700 (PDT)
Received: by 10.180.14.69 with SMTP id n5mr1494106wic.4.1337068090614;
        Tue, 15 May 2012 00:48:10 -0700 (PDT)
Return-Path: <m...@misto.ch>
Received: from lucius.metanet.ch (lucius2.ch-meta.net. [80.74.131.3])
        by gmr-mx.google.com with ESMTPS id er1si6688551wib.0.2012.05.15.00.48.10
        (version=TLSv1/SSLv3 cipher=OTHER);
        Tue, 15 May 2012 00:48:10 -0700 (PDT)
Received-SPF: neutral (google.com: 80.74.131.3 is neither permitted nor denied by best guess record for domain of m...@misto.ch) client-ip=80.74.131.3;
Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 80.74.131.3 is neither permitted nor denied by best guess record for domain of m...@misto.ch) smtp.mail...@misto.ch
Received: (qmail 29177 invoked from network); 15 May 2012 09:48:10 +0200
Received: from unknown (HELO pin6108475.localnet) (152.96.200.155)
  by luc80-74-131-153.ch-meta.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 15 May 2012 09:48:10 +0200
From: Mirko Stocker <m...@misto.ch>
To: scala-ide-dev@googlegroups.com
Subject: Re: [scala-ide-dev] Spring cleanup of the scala-ide repository
Date: Tue, 15 May 2012 09:48:09 +0200
Message-ID: <4696082.30e4fRiNKj@pin6108475>
User-Agent: KMail/4.8.3 (Linux/3.3.3-gentoo; KDE/4.8.3; x86_64; ; )
In-Reply-To: <E1CC3B9A-568B-4D08-9D92-4A14C1E0A688@typesafe.com>
References: <CAOwe9fbXzMOgNMJmcdnzyc9qQY42QtbzR9w3i4=0hfYsNwR7XQ@mail.gmail.com> <CAN4BhaKZgv5wM2QqkdHbwN_AQsu=TaeXgvBUq4iLLH4VofvfvA@mail.gmail.com> <E1CC3B9A-568B-4D08-9D92-4A14C1E0A688@typesafe.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"

Hi,

Oops, I missed the replies from Luc and Mirco..

It occurred to me that there are more benefits to Iulian's proposal: we=
 will=20
get less notification-noise from merges in branches, and commits to a b=
ranch=20
won't close Assembla tickets before they have been merged to master.

Maybe we could adapt GitHub's =ABOpen a Pull Request as early as possib=
le=BB=20
principle, that way we can still see what things are being worked on?

Cheers,

Mirko


[1] https://github.com/blog/1124-how-we-use-pull-requests-to-build-gith=
ub


On Tuesday 08 May 2012 09:52:31 Mirco Dotta wrote:
> On May 7, 2012, at 7:25 PM, Mirko Stocker wrote:
> > Hi,
> >=20
> >> There is one small downside: developing
> >> everything in branches leads to a lot of unnecessary/old/dead bran=
ches
> >> that
> >> need to be removed after a successful merge. Most of us forget to =
do
> >> that.
> >=20
> > While thinking about this, I found some useful commands for this ki=
nd of
> > work:
> >=20
> > git branch -r --merged
> >=20
> > When run from master, all these branches could be deleted because
> >=20
> > they've been merged into master:
> >  origin/feature/allow-sbt-to-change-the-order-of-compilation-100066=
4
> >  origin/feature/find-references-1000698
> >  origin/feature/surround-selection-1001010
> >  origin/feature/tuning-semantic-highlighting
> >  origin/issue/hyperlink-to-implicit-1001002
> >  origin/issue/iindex-value-for-arrays-1001009
> >  origin/issue/jdk-1000406-again
> >  origin/issue/multiple-errors-1000735
> >  origin/issue/open-declaration-fails-from-popup-menu-1000920
> >  origin/issue/overlong-problem-markers-1000671
> >  origin/issue/show-only-accessible-members-1000784
> >  origin/issue/show-type-of-selection-1000954
> >  origin/issue/todo-1000634
> >  origin/issues/equinox-hook-1000918
> >=20
> > --no-merged shows the un-merged branches, but again, from the
> > perspective of the current branch.
>=20
> Really useful commands, thanks!
>=20
> >> Everyone, including committers, would issue pull-requests from the=
ir own
> >> forks. Given the distributed nature of Git, and the great support =
in
> >> Github, I don't foresee any problems or extra work.
> >>=20
> >> Thoughts?
> >=20
> > I see just one risk, it's easier to miss an unmerged branch if it i=
s
> > in a different repository.
>=20
> This risk is existing also right now, none of us is actually looking =
at what
> has been merged vs not-yet-merged. Hopefully, working on a fork will =
push
> people to integrate changes back asap.
>=20
> > And, doesn't it make working together on a
> > feature more complicated? If I have to fork the fork and then send
> > pull requests for the fork.. seems messy.
>=20
> As Luc said, no need to fork the fork, just add the upstream (the per=
son
> with whom you are collaborating has to give you write access to the r=
epo,
> of course)
>=20
> =09http://help.github.com/fork-a-repo/
>=20
> > Cheers,
> >=20
> > Mirko
>=20
> ---------------
> Mirco Dotta
> Typesafe - The software stack for applications that scale
> PSE-D, 1015 Lausanne, Switzerland
> Work: +41 (0)21 691 49 65
> Twitter: @mircodotta
--=20
Mirko Stocker | m...@misto.ch
Work: http://ifs.hsr.ch | http://infoq.com
Personal: http://misto.ch | http://twitter.com/m_st