Convert repo to use git-submodules

[Ethan]

Google(Shawn Pearce) has done an awesome job with their tool repo for
android source management. I feel that it would be great if git-
submodules could gain some of it's features. In my opinion porting
repo to use git-submodules should be a fairly easy process.

TODO
- git-clone needs an option to clone hook scripts.
(Reasoning: So that uploading to isssue tracker Gerrit can
be setup properly.)
(Reasoning: So that tarballs can be copied into dir
similar to repo.)
- git-submodule needs to be augmented (rm, mv)

I've created a proof of concept repo. Please let me know what you
think of this idea. I apologize if someone has mentioned it before.

http://github.com/ethanvandenberg/androidsubmodules/tree/master

[Shawn Pearce]

On Wed, Nov 5, 2008 at 12:26, Ethan <ethan.va...@gmail.com> wrote:

 Google(Shawn Pearce) has done an awesome job with their tool repo for
android source management. I feel that it would be great if git-
submodules could gain some of it's features. In my opinion porting
repo to use git-submodules should be a fairly easy process.

The Android team specifically chose to avoid git-submodule because they didn't want to deal with commits and merges in the super-project.  That and git-submodule is a bit difficult to use.  So repo allows tracking branches instead of commits.
 

TODO
   - git-clone needs an option to clone hook scripts.
           (Reasoning: So that uploading to isssue tracker Gerrit can
be setup properly.)

I'm not sure what you need hooks for.
 

           (Reasoning: So that tarballs can be copied into dir
similar to repo.)

We actually backed away from this use of tarballs.  Its far slower than just getting everything over git://.
 

   - git-submodule needs to be augmented (rm, mv)

 
Totally unrelated to Android or repo, this is just one of the things about git submodule.  :-)

I've created a proof of concept repo. Please let me know what you
think of this idea. I apologize if someone has mentioned it before.

http://github.com/ethanvandenberg/androidsubmodules/tree/master

Nope, it hasn't been discussed before on the list, but the reason we made repo was because we didn't want to deal with commits in the super project, or trying to merge concurrent branches in the super project.  Instead we wanted each subproject to use a floating branch as the revision it is tracking.

[Ethan]

Thank-you so much for the quick response. I'm sure you have discussed
all these issues internally, I appreciate your patience.


-> So repo allows tracking branches instead of commits.

I would argue in the opposite direction. I'd say commit rather than
branch level tracking is absolutely critical. I feel that repo does
not capture the following workflows(mainly future concerns):
1. How do I check-out/commit a specific versions of the os? (by
platform or version number)
2. How do I quickly ensure that multiple subprojects are at a
specific version(not head) so that I can test a feature. Without going
into each one.
3. How do I track the source for os builds over time?
Basically I have no way to track the entire project over time.


-> I'm not sure what you need hooks for.

This is not a fully developed idea. I wanted to put the upload.py in
a post-commit hook (or merge,pull etc ) so I would be prompted if I
wanted to upload it to Gerrit for review. And I thought it would be
handy if these scripts were put into place without me having to
explicitly to so. Not an android specific issue though.


-> That and git-submodule is a bit difficult to use.

Although it may be hard to use right now determining the divider
between these two tools re-inserts much of the complexity and
difficutly of use. I do believe we are better served by having one
tool "git" and leveraging repo's great ui and git's already existent
developer community. Repo is a great tool and I really believe every
effort should be made to make it part of git-core. Either as git-
submodule or something else.


-> Nope, it hasn't been discussed before on the list, but the reason

we made repo was because we didn't want to deal with commits in the
super project, or trying to merge concurrent branches in the super
project. Instead we wanted each subproject to use a floating branch
as the revision it is tracking.

In my opinion since none of the content is being tracked in the
super-project, merges and commits should be much easier to deal with
than any of the other sub projects. Or maybe I'm misunderstanding?