Git tooling (repo, submodules, etc)

We’ve seen a bit of breakage recently around the repo manifests recently that has caused some issues for people (some including needing to recheckout if I’m remembering correctly) and I wanted to ask the question if repo is the best tool we could be using to manage some of the complexities of git repository management.

Personally, I have an immense dislike of repo (I’ve used it on multiple projects now and have yet to have it work as needed) and tend to use git-submodules (which has its own issues IMHO). I’ve talked with Tom Rini about this before and he suggested looking at kas which I’ve not used.

So. Thoughts? Is repo the right tool? If so, how can we keep it from bodgering workspaces? If not, what is the better option.

1 Like

I would love if we could collect feedback from our colleagues in China, who work on Harmony, to see if they are hitting any issues with repo or if they had similar thoughts.

Could perhaps @L86740 help us collect this information somehow?

1 Like

In the past I have worked with submodules in complicated projects and run into a number of recurring problems: overwritten branches with git submodule update, forgetting to update the reference when commiting a change, integration with the CI and more. For now I have less issues with repo (not that they are none). Willing to give kas or any other tool a try.

1 Like

IMHO gitmodules are better for pinning deps but less convenient when working with developments branches.

I would not recommend it over repo and I am not sure submodules would simplify our works,
some of us are not yet truly comfortable along git itself.

Kas looks promising its more devops oriented isnt it (yml):

https://kas.readthedocs.io/en/latest/

That said I’ll be curious to know @pidge’s arguments against repo (beside it’s xml)

I’ve had these problems with both repo and with git submodules. The git submodule user interface is very different from normal git usage in my mind and makes it hard for people that aren’t git experts. I’ve also used git subtree that solves some of the problems but introduces new ones.

As a git submodules user, I’ve found updating from upstream to be a bit unintuitive. This comparison sums it up nicely: `

Submodules are easier to push but harder to pull – This is because they are pointers to the original repository.

My original vote for repo wasn’t based purely on technical merit because that would be a bike-shedding discussion :grinning: - it was based on the fact that repo is familiar to lots of people that work on AOSP. And that happens to be some of the developers we’re trying to attract.

Can we distill down the usage of git submodules or other replacement options down to a page of documentation for potential contributors?

I think we should consider training of potential contributors as a factor in choosing a replacement.

1 Like

I think we need to accept that working in a multi-repository setup is complicated enough, that no matter which tool we use to manage it, there will be complications and issues.
So any tool we are using, or considering to use, will have issues.

That said, my personal preference is to use git submodules. I have used it a lot in the past, and believe that it (in its current modern form) don’t have any more issues than what comes with working with a mult-repository setup.

It is also worth noting, that GitLab CI has built-in support for working with submodules, making it easy to work with manifests with private or internal repositories in submodules.

Being new to repo, I honestly think that it is much much less intuitive than git submodules. I haven’t actually figured out yet how it truly works, and how I am supposed to use it. It seems most like a black box where you writer repo sync and hope it did what you wanted, and if not, wipe the entire thing and start from scratch. I am sure I will learn it over time, but for now, the development experience is less than attractive.

1 Like

Interesting situation, let me fire a survey for what you think is preferred for the team (not only your personal preference)

  • git submodules
  • repo
  • kas
  • something else
  • not answering for some reason

0 voters

Let me crosslink to related draft:

I was wondering how consumer could encapsulate oniro into its downstream project.
I can explain deeper if any interest.