Branches, problems and solutions

[Ulrik Sjölin]

Hello Shawn,

A problem we are starting to run into is that we have developers that
need to work on isolated branches for new development in one or more
gits. This is easily accomplished by branching all gits and flipping
the default revision in the manifest, but rebasing this branch becomes
a nuisance. Right now we get by fairly well with local manifests and
creation of branches in the subset of gits where they make changes,
but as the number of affected gits grows the situation becomes worse.
Running “repo sync” with such a setup requires developers to either
explicitly sync only the gits they have branched or they need to
rebase all their code every time in order to keep up with the possible
inter-git dependencies between branched and non-branched gits.

If we branch all gits we solve this problem of keeping development
branches completely isolated between explicit rebase operations, but
that would either require us to grant push permissions to all
developers, have a few trusted and competent people rebase the
developers’ branches, or ask developers to upload and approve merge
commits in 200+ gits.

We’re therefore considering different ways of allowing developers to
keep their branches stable while still making it easy to rebase them
from an upstream branch. Apart from literally branching and fast-
forwarding branches, one way would be to use the manifest to peg the
unbranched gits to specific revisions and upon request get help from
Repo or Gerrit with updating the manifest with fresh upstream SHA-1s.
This would require teaching Repo how to push and make changes to the
manifest and it would also require teaching Gerrit a few new tricks.
Would a change like this be aligned with the "new manifest format"
change? We are very interested in implementing something like this
would you consider taking it in?

Ulrik Sjölin

[Shawn Pearce]

Ulrik Sj�lin <ulrik....@gmail.com> wrote:
> We?re therefore considering different ways of allowing developers to

> keep their branches stable while still making it easy to rebase them
> from an upstream branch. Apart from literally branching and fast-
> forwarding branches, one way would be to use the manifest to peg the
> unbranched gits to specific revisions and upon request get help from
> Repo or Gerrit with updating the manifest with fresh upstream SHA-1s.

Yup.

> This would require teaching Repo how to push and make changes to the
> manifest and it would also require teaching Gerrit a few new tricks.

Yup. My plan with atomic sync was to teach Gerrit to update the
manifest, and repo wouldn't generally do that.

> Would a change like this be aligned with the "new manifest format"
> change? We are very interested in implementing something like this
> would you consider taking it in?

Yes.

My plan on the new manifest format was to have Gerrit scan the
.gitmodules file and store in a database table the projects and
branches which need to be updated whenever another project is
updated:

.gitmodules:
[submodule "platform/apps/Clock"]
path = apps/Clock
url = git://vcs.example.com/ClockWidget.git
revision = .

Gerrit code:
public class ManifestModule {
protected String manifestProject;
protected String manifestBranch;
protected String sourceProject;
protected String sourceRevision;
}

In above example:
manifestProject = 'platform/manifest'
manifestBranch = 'refs/heads/eclair';
sourceProject = 'platform/apps/Clock';
sourceRevision= 'refs/heads/eclair';

Anytime Gerrit updates platform/apps/Gerrit branch eclair then it
should also update project platform/manifest, branch eclair, at
path apps/Clock to point to the new commit.

If you guys want to take this on and try to do work on it, I would
greatly appreciate it.

[Ulrik Sjölin]

I think I need some more details here ;-)

Lets say we have a manifest with 4 projects: A, B, C, D. A developer
makes changes to A and B that requires C and D to stay in their
current version to work. When this developer pushes his changes to
Gerrit, the manifest is updated (if someone syncs at this point,
things will work). Another developer pushes changes to C (that breaks
the new versions of A and B), wouldn't a third developer get in
trouble when he synced at this point?

The idea we have is that the developer would branch the manifest,
later when the developer wants to upload the changes, repo would make
the changes in the manifest to point to the new branches of A and B.
Gerrit would store the commits on a branch (using same name as the
branch of the manifest?) of A and B and finally also push the changed
manifest. This way the manifest would always point out "compatible"
versions of the components. Repo sync would fetch new changes but not
change anything in the working directory, this is where we would like
to teach Repo a new subcommand that will "fast-forward" by moving the
"unbranched" projects C and D pointers in the manifest to that of the
latest version of the parent manifest.

[Shawn Pearce]

On Thu, Dec 10, 2009 at 12:47, Ulrik Sjölin <ulrik....@gmail.com> wrote:
> Lets say we have a manifest with 4 projects: A, B, C, D. A developer
> makes changes to A and B that requires C and D to stay in their
> current version to work. When this developer pushes his changes to
> Gerrit, the manifest is updated (if someone syncs at this point,
> things will work). Another developer pushes changes to C (that breaks
> the new versions of A and B), wouldn't a third developer get in
> trouble when he synced at this point?

Yes.

But in your case, the manifest would *NOT* have a revision property in
.gitmodules for the C and D projects. By omitting revision property,
Gerrit would not create (or would delete) the matching ManifestModule
record from the database, so future updates to C or D would not
produce a match, and Gerrit would not update the corresponding
manifest.

[Ulrik Sjölin]

Have you any thoughts around merging/rebasing manifests? How should
the user be supported there?

[Shawn Pearce]

Ulrik Sj�lin <ulrik....@gmail.com> wrote:

> Have you any thoughts around merging/rebasing manifests? How should
> the user be supported there?

Yuck. No, I hadn't put a lot of thought into that.

Actually, git will handle either operation just fine, for the
most part. So long as there isn't a conflict on a given project
the merge or rebase would go through cleanly.

On a conflict the three commits (ancestor, ours, theirs) are left
in the index for the user to resolve. repo could do some magic
looking to see if theirs or ours is a superset of the other one,
and if so fast-forward the project to the superset. This should
actually already be a feature of `git submodule`, I wonder if we
can't just reuse that to help resolve these conflicts.