Cascaded git repositories, SoCs Linux kernel
I open this question in order to get more understanding of
the git repository dependencies in project of the kind addressed below.
As for instance the OMAP or MSM SoC hardware platform evolve from ARM architecture the same way the development of Linux kernel might be organized:
Linus vanilla kernel repository >> ARM adaptations kernel repository >> vendor’s SoC adaptations kernel repository.
“>>” means the direct relation between parent-clone repositories.
So, if the above is true, there should exist a cascade of repositories. The local repository cloned from vendor’s SoC kernel repository for purposes of patch development or similar as the latest stage in cascade.
I guess, due to delays in upstreaming to Linus tree it is recommended to clone from platform project repository, not directly the vanilla Linux.
Linaro seems to be collaborate platform for ARM.
Code Aurora Forum seems to be some additional collaborate platform.
Both might contribute to the final kernel for the addressed platform.
Possibly there exist more Open Source collaborate platform than those two above
and involved in the cascade.
How to list the remotes of my repository’s remote?
git branch -r
provides the list of remote tracking branches with list item also in following form
The question is what do all the path level refer to? Are these the parent branches, or rather parent remotes?
2 Solutions collect form web for “Cascaded git repositories, SoCs Linux kernel”
First of all you have to distinguish
branches in index. All operations with
remotes are made by
git remote ….
And thus the answer 1.
git remote -v will show you detailed list of remotes you are subscribed to.
The answer 2 a bit fuzzy since you have to be involved a bit into the project you are talking about. So, usually first part is remote, second one is branch in this specific remote. Note, by the way, that branch names can contain ‘/’ characters but it has nothing to do with any actual path! Just a convenient name let’s say.
Way how I deal with repositories (I have to change this a bit because of new feature of git 2.5.0+) is to clone master repository of the project, origin as linux-kernel, then I add remotes, for example I have stable as linux-stable, and next as linux-next. This is a bare repository (no working directory). Then I create few additional reference repositories to this one. And I add as many additional remotes I want to this repositories. Usually I have few subsystem based trees added to one of repository (like spi or tty-next) and my experimental stuff in another repository.
+----------------------------+---------------------------+ | | | | +------v------+ | | | REFERENCE | | | | | | | | origin | | | +-------------+ | | +-------------+ | | | TOPIC REPO1 | | stable | | TOPIC REPO2 | | | | | | | | | | +---+ (reference) | | next | | (reference) +--+ | | +-------------+ | | | branch X | | branch Y | +-------------+ | | | spi | | | | tty-next | +-------------+
In the given situation git is not used for active contribution in project. The soc vendor provides its public git URL and all needed references. My project includes sources snap-shot fetched from that git (that fetch was not my job) but being under version control, however not git’s VC. Then my job is to compile and build together with sources of own code and other components received over other distribution channels. Every time the soc vendor provides new references to public git state due to changes in base-line I get it provided in my project as ready to use sources.
The problem is the soc vendor is not always quick enough if it comes to delivering patches or bug fixes. So the idea is to gain more independence – as patches provided by vendor mostly come from public git repository it should be possible to be little bit independent. Why not to browse the history of public repository used by soc vendor by my own and look if needed changes are available on some other branch. Then to examine if the finding qualifies to be applied in my project. Sure, there will be cases that needed change won’t be to found on no branch of soc vendor’s public git because nowhere existent, on no repo, on no branch.
Therefore I cloned the public repo used by soc vendor to my private one. No local branches were created in private repo. Mines private repo will be used to browse the history and search for needed stuff – no active collaboration in development. Branch name can be one of criteria helpful in the judgement how much the patch found on it suitable for application in my SoC/project. The problem is that repo and its history show huge number of branches. Frequently I have to wonder what does the particular branch listed as remote tracking branch has in common with the used soc or board. The possible reason might be that my remote (at this moment my local repo has only one remote) inherited them from its remotes.
Furthermore, I wonder if the soc vendors public repo clones directly from Linux tree or rather from ARM adaptations public repo as the SoC is based on ARM cores.
Therefore the Question 1 asked initially. That question reads which remotes does the remote of my private repo use. So please understand I can’t accept your answer as answer.
Reg question 2 answer:
I conclude from your answer the particular element between two slashes is a branch reference. Is this a branch hierarchy on one single remote, the remote of my private repo? Or is it rather the hierarchy of remote repos (cascade)?
By gathering the addressed knowledge I aim the ability in discounting completely irrelevant branches while browsing the history. I aim more orientation in how the branch used in my project relate to other existing branches.
I use the Pro Git book to get familiarized with git.
The book does not answer all of my questions.