On Fri, Jun 5, 2015 at 9:59 AM, Gao, Liming <liming....@intel.com> wrote:
> Thanks for your all comments. Those gives me more concept of Git.
>
> I want to clarify my usage model. My daily work bases on internal project
> to develop features for external and internal packages both. So, I expect I
> have one git repo (one GIT URL) to get all required packages (internal and
> external), then base on it to pull the update, create patch, review patch,
> and push my changes for internal and external. I also hope I can use Git
> advantage usage for EDKII and my internal project. But, I find no obvious way
> to support this usage. Submodule is a little complex. Repo tool is not easy
> to be used in Windows. And, even if we use Repo tool, we still need to
> separate internal Package as single Repo, then combine them one by one into
> EDKII as my internal project. git filter-branch can split Package from EDKII
> Repo. But, this ways need script to update code. And, I am not sure whether I
> can base on filter-branch to push my changes. After compare them, I think
> submodule is the simplest way to support my usage model. So, I propose to
> separate Package as Repo, keep Package Repo as upstream Repo and EDKII Repo
> as read only. If Package Repo is read only, EDKII Repo is upstream Repo, it
> will bring a little burden for me. But, it is also an acceptable solution.
Hi Liming,
I don't understand what you are proposing - can you please explain
it in more detail?
>
> Last, I don't understand why GIT not smoothly supports my usage model,
> because it is just designed for Linux project?
Yup - that is the only use case the original design considered. It
has grown some more features as other projects adopted it, but for
some use cases subversion is much more usable.
Roy
>
> Thanks
> Liming
> -----Original Message-----
> From: Roy Franz [mailto:roy.fr...@linaro.org]
> Sent: Friday, June 5, 2015 12:34 AM
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] Proposal of Git Repo Layout for EDKII project
>
> On Thu, Jun 4, 2015 at 8:58 AM, Brian J. Johnson <bjohn...@sgi.com> wrote:
>> On 06/03/2015 08:53 PM, Jordan Justen wrote:
>>> Yet another idea that I've considered is trying to leverage git
>>> subtree. My idea was that the unified EDK II would remain the main
>>> upstream.
>>>
>>> I would setup an automated process to split each package off using
>>>git subtree, and push the separate repos.
>>>...
>>>
>>> I never got the time to investigate if git subtree could work as
>>> required, but this text from the help page seems promising:
>>>
>>> "
>>> split
>>>
>>> Extract a new, synthetic project history from the history of the
>>> <prefix> subtree. The new history includes only the commits
>>> (including merges) that affected <prefix>, and each of those
>>> commits now has the contents of <prefix> at the root of the
>>> project instead of in a subdirectory. Thus, the newly created
>>> history is suitable for export as a separate git repository.
>>>
>>
>> I experimented with git subtree a couple years ago for managing a
>> project composed of multiple sub-projects. I'm trying to remember
>> what I thought about it.... It works, but it tends to produce a
>> confusing git log, IIRC. And if you're going to push to the subtrees,
>> you should be careful to limit each commit to files in a single
>> (sub)tree. That requires developer discipline, or a good pre-commit hook.
>>
>> But for extracting packages into separate read-only repos, it should
>> be perfect. Note that in that mode, it's very similar (or completely
>> equivalent?) to "git filter-branch --subdirectory-filter".
>> --
>>
>> Brian J. Johnson
>>
>
> If git subtree can be used to create and maintain read-only "modules" based
> on the single master git repo, this sounds like a good solution. This keeps
> the single git repo as the master, and avoids the complications of commits
> that cross module boundaries in the sub-module case. If git subtree can
> support this usage model, would read-only git subtrees for the modules meet
> the requirements for those who want to use "modules" individually? Note that
> only the upstream subtree repos are read-only, various other groups could
> still have internal read/write repos cloned from those, it's just that
> changes pushed upstream would need to go through the master git tree.
> If this is a generally acceptable plan, then I guess a next step is to verify
> that git subtree works as desired.
>
> Roy
>
>
>> --------------------------------------------------------------------
>>
>> My statements are my own, are not authorized by SGI, and do not
>> necessarily represent SGI’s positions.
>>
>> ----------------------------------------------------------------------
>> -------- _______________________________________________
>> edk2-devel mailing list
>> edk2-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
> ------------------------------------------------------------------------------
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
> ------------------------------------------------------------------------------
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
