[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [git] How to organize 3.x and 4.x development in Git

You're right of course. Since these are commits that are already out on the remote server we would need to merge rather than rebase. Thanks Steffen.


Steffen Pingel <steffen.pingel@xxxxxxxxxxx>
Sent by: git-bounces@xxxxxxxxxxx

08/16/2011 02:36 PM

Please respond to
"Git related discussions,        specifcally migration help for projects at Eclipse.org"        <git@xxxxxxxxxxx>

"Git related discussions,        specifcally migration help for projects at Eclipse.org" <git@xxxxxxxxxxx>
Re: [git] How to organize 3.x and 4.x development in Git

For Mylyn we had to branch one of our repositories as well to maintain separate streams for two bundles. We are doing something similar to (2) but instead of rebasing I run "git merge origin/master" before integration builds to update the branch. So far overhead has been low but admittedly differences between streams are minimal so far so merging hasn't caused any conflicts, yet.

While rebasing avoids merge commits it has more potential for conflicts since each incremental change is re-applied each time. It will also change commits in the branch which causes problems for anyone who has cloned the repository and based work of those commits.


On Tue, Aug 16, 2011 at 7:37 PM, John Arthorne <John_Arthorne@xxxxxxxxxx> wrote:

Eclipse Platform UI has roughly 40 plugins in a single Git repository. Two of those plugins have code differences between the 3.x and 4.x streams. Since branches in Git operate at the granularity of a whole repository, it means 38 plugins need to maintain identical contents in those two branches. In CVS this problem was easy because individual folders in the repository could be forked independently. The question is, how do we organize our development in a way that minimizes pain for committers and avoids too many manual steps prone to user error.

Possible Solutions:

1. Do all development in master (4.x), and then cherry-pick each commit over to the 3.x branch. Commits that involve both split and non-split bundles would need to be merged manually. This is what the team is doing today. It works, but there is a chance committers will forget to merge every change across to 3.x, and it adds extra overhead for committers every time they make any code change (make change, run tests, commit to master, push, checkout 3.x, find and cherry-pick the commit, test, push to 3.x, checkout master again).

2. Do all development in master (4.x), and once a week rebase the 3.x branch to pick up all the changes made in master (perhaps a single person does this as part of 3.8 build submission procedure). This avoids the overhead for each commit, but has a once a week pain of performing that rebase and manually merging any conflicts.

3. Maintain two separate Git repositories - one for the two split plugins, and one for the 38 plugins that are not split. This mimics the setup we had in CVS and avoids any extra pain on developers for maintaining two branches for things that don't actually need to be branched. The big downside is that if we later decide to split more plugins (quite likely), they would need to be transferred over to the "split plugins" repository. Moving subtrees across git repositories while maintaining all their commit history is a painful operation. Over the long term, splitting repositories along the lines of what is forked and what isn't is going to be a headache.

4. Do all development in master (4.x), and don't bother porting back to 3.8 stream unless it is a critical bug (treat 3.8 purely as critical maintenance).

Are there any other suggestions for how to organize development in this scenario? Are there other advantages/disadvantages to the above solutions that I am forgetting? What is the current preference among Platform UI committers?

Separate from how we actually do the development, I was thinking it would be useful to have a verification script that checks out master and 3.x streams and verifies that the 38 non-split plugins are identical. This could at least help catch any cases of user error that could come up with 1. and 2. If there are existing tools out there to do that in Git, please chime in.


git mailing list


Steffen Pingel
Senior Developer,
git mailing list