Spring cleanup of the scala-ide repository

[iulian dragos]

Dear all,

The move to Github was an unquestioned success, and channelling everything through pull-requests and code reviews increased the quality of the code and the visibility of our work. There is one small downside: developing everything in branches leads to a lot of unnecessary/old/dead branches that need to be removed after a successful merge. Most of us forget to do that. As a result, the repository looks hectic.

I propose we change the workflow slightly, and the scala-ide repository contains only the 'main' builds:

- master

- release/2.0.x (any number of them)

- platform/juno (any other platforms)

Everyone, including committers, would issue pull-requests from their own forks. Given the distributed nature of Git, and the great support in Github, I don't foresee any problems or extra work.

Thoughts?

If no one objects, please review any outstanding branches in the repository that you created, and please remove them if they've been merged.

thanks,

iulian

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

[Mirko Stocker]

Hi,

> There is one small downside: developing
> everything in branches leads to a lot of unnecessary/old/dead branches that
> need to be removed after a successful merge. Most of us forget to do that.

While thinking about this, I found some useful commands for this kind of work:

git branch -r --merged

When run from master, all these branches could be deleted because
they've been merged into master:

origin/feature/allow-sbt-to-change-the-order-of-compilation-1000664
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

--no-merged shows the un-merged branches, but again, from the
perspective of the current branch.

> Everyone, including committers, would issue pull-requests from their own
> forks. Given the distributed nature of Git, and the great support in Github,
> I don't foresee any problems or extra work.
>
> Thoughts?

I see just one risk, it's easier to miss an unmerged branch if it is
in a different repository. 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.

Cheers,

Mirko

--
Mirko Stocker | m...@misto.ch
Work: http://ifs.hsr.ch | http://infoq.com
Personal: http://misto.ch | http://twitter.com/m_st

[Luc Bourlier]

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

Just to answer this specific point, you should not have to fork the fork. After adding the fork as a remote to your local clone, you should be able to check out any branch from it. (I haven't tried it this way (pulling), but it works fine for pushing in a different remote).

Luc

[Mirco Dotta]

Really useful commands, thanks!

Everyone, including committers, would issue pull-requests from their own

forks. Given the distributed nature of Git, and the great support in Github,

I don't foresee any problems or extra work.

Thoughts?

I see just one risk, it's easier to miss an unmerged branch if it is
in a different repository.

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.

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.

As Luc said, no need to fork the fork, just add the upstream (the person with whom you 

are collaborating has to give you write access to the repo, of course)

http://help.github.com/fork-a-repo/

Cheers,

Mirko

--
Mirko Stocker | m...@misto.ch
Work: http://ifs.hsr.ch | http://infoq.com
Personal: http://misto.ch | http://twitter.com/m_st

---------------

Mirco Dotta

Typesafe - The software stack for applications that scale

PSE-D, 1015 Lausanne, Switzerland

Work: +41 (0)21 691 49 65

Twitter: @mircodotta

[Matt Russell]

On Monday, May 7, 2012 1:18:19 PM UTC+1, Iulian Dragos wrote:

 

Everyone, including committers, would issue pull-requests from their own forks. Given the distributed nature of Git, and the great support in Github, I don't foresee any problems or extra work.

Thoughts?

If no one objects, please review any outstanding branches in the repository that you created, and please remove them if they've been merged.

Sounds good -- I've found it pretty straightforward to work with multiple remotes in Git. I've pruned one branch; there's one remaining from an outstanding pull-request which I can remove later.

-- Matt

[Mirko Stocker]

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
get less notification-noise from merges in branches, and commits to a branch
won't close Assembla tickets before they have been merged to master.

Maybe we could adapt GitHub's «Open a Pull Request as early as possible»
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-github