about autoimport code from private branch to public GIT

26 views
Skip to first unread message

johnny

unread,
Jul 25, 2009, 9:47:31 AM7/25/09
to Repo and Gerrit Discussion
Hi Shawn,

In the commit message we see lots of comments like "autoimport from
private branch xxx". I guess that Google developers should work on a
private GIT repository. Once the code reaches a certain quality, the
code is autoimported to the public GIT repository. Is that the way
cupcake and donut release is developped?

I wonder if you could share any BKM on how this autoimport is done.
For example, does autoimport uses "git merge" to merge the public
branch and private branch or uses a "replace" method to make sure that
public git tree has the same code as that of private git tree.

Thanks,
Johnny Xia

Jean-Baptiste Queru

unread,
Jul 25, 2009, 11:12:23 AM7/25/09
to repo-d...@googlegroups.com
Actually, the auto-imports are/were used to import changes from our
legacy source code management system, which is where Cupcake an older
versions were developed (and where Donut was started for a short time
while we were transitioning to git).

Git's distributed nature means that there's no need to explicitly
re-write commits to import them, fetching/pushing them across is
enough to achieve the same goal (and it's much easier). Git is the now
the only source code management system we use for Donut and above
(legacy system is still being used to maintain Cupcake). The git
objects pushed in the public Android tree are exact copies of the ones
on Google's private servers, and the ones contributed into the
open-source project end up unmodified into Google's private servers.

The auto-imports write to branches that aren't modified by anybody
else, and one way to perform such an import is "rm .git/index ; git
clean -fdx ; (populate new snapshot) ; git add . ; git commit"

JBQ
--
Jean-Baptiste M. "JBQ" Queru
Software Engineer, Android Open-Source Project, Google.

Questions sent directly to me that have no reason for being private
will likely get ignored or forwarded to a public forum with no further
warning.

johnny

unread,
Jul 27, 2009, 1:51:25 AM7/27/09
to Repo and Gerrit Discussion
Got it.

Could you explain more about "the ones contributed into the
open-source project end up unmodified into Google's private
servers." ?

If a developer commit code to cupcake branch in public server, will
you pull those commits to private server?

Thanks,
Johnny Xia

Jean-Baptiste Queru

unread,
Jul 27, 2009, 1:59:01 AM7/27/09
to repo-d...@googlegroups.com
While we don't do it for cupcake (mostly because our primary cupcake
branch is on a pre-git legacy system), we do it for master, yeah.

At the moment those are done manually (I do them), and I'm hoping to
automate that in the future.

JBQ

johnny

unread,
Jul 27, 2009, 11:22:56 AM7/27/09
to Repo and Gerrit Discussion
How about the release branch, did you do it for donut branch?

I'd also like to setup a private and public GIT server and can
automate the sync between private server and public server. Here is my
rough plan, please feel free to comment.

1. Push code from private server to public server using "replace"
method with the way you mentioned:"rm .git/index ; git
clean -fdx ; (populate new snapshot) ; git add . ; git commi". So that
we can make sure public server has exact same code as private server.

2. Pull code from public server to private server. Using "git cherry-
pick <commit>" to pick certain commits from public server.

Thanks,
Johnny Xia.

Jean-Baptiste Queru

unread,
Jul 27, 2009, 12:31:08 PM7/27/09
to repo-d...@googlegroups.com
We do have a donut-release branch internally, which only differs from
the donut branch by its version number.

As for your plan, this sounds like it should be workable, but it seems
to me that you're not benefiting from the distributed aspect of git -
pushing snaphots out and cherry-picking changes back in is in fact
very similar to what would happen with a non-distributed system.

Personally (and that's really just a personal opinion, YMMV), I prefer
processes where work across servers limits itself to fetching from one
server and pushing to another via a fast-forward, and where anything
more complex happens within the confines of a single server.

E.g. imports from the Android Open-Source Project are done in two
steps: mirroring the external tree on Google's internal server, and
merging the mirror into our work tree (we use merges instead of
cherry-picks as we actually take all changes in, and as it better
preserves the history and allows fast-forwards more often than not).

Similarly, pushes from Google's work tree to the Android Open-Source
Project are first staged on our internal server, and then pushed to
kernel.org (so that any specific work that needs to happen during
staging can happen behind closed doors).

JBQ

johnny

unread,
Jul 27, 2009, 11:02:29 PM7/27/09
to Repo and Gerrit Discussion
Thanks Jean-Bapstiste.
Reply all
Reply to author
Forward
0 new messages