[git] How to organize 3.x and 4.x development in Git

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

Problem: 

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.

john