GIT and Cloning Remote Repositories into "Local Remote" Repositories

I'm still in the stage of using GIT where I "know enough to be dangerous". That said, I am trying to set something up and get it "right" to avoid pain later. However, after reading GIT online help and various FAQs, it is still unclear what the right thing or steps to perform are.

Here's the scenario:

1) I have a private repository set-up at GitHub that I can commit, push and
pull to my heart's content. This is all working well.

2) I now need to import some third-party software, two packages in
particular (U-Boot and Linux), at specific tags into subdirectories within
my repository in (1).

3) Changes in these subdirectories in (2) should ONLY go to GitHub but NEVER
to the origin of the clone UNLESS the user (usually me) really knows what
he/she is doing.

I know how to use 'git clone' to clone a remote repository and make local commits there; however, what I think I want is a 'clone into':

    % cd <path to the local copy of my GitHub repo>
    % git clone <URL to package A @ tag S> <package A subdirectory>
    % git commit -m "Imported package A @ tag S" <package A subdirectory>
    % git clone <URL to package B @ tag T> <package B subdirectory>
    % git commit -m "Imported package B @ tag T" <package B subdirectory>
    % git push

Some time later, when Package A or Package B is updated to a new release tag, I'd like to be able to choose (but not automatically) to merge those changes in with my own changes and then update my GitHub repository.

Perhaps 'submodules' are what I am looking for?

Anyone have a good recipe or good hygiene/best practice recommendations for this?

Best,

Grant Erickson

On Mon, Sep 20, 2010 at 06:22:09PM -0700, Grant Erickson wrote:

Yup, exactly :) the manpage git submodule should get you going.

--CJD

On 9/20/10 6:37 PM, Casey Dahlin wrote:

Casey:

Thanks for the prompt reply.

I spent some time over the weekend playing with the various submodule tutorials and I wasn't left feeling convinced that it's the right solution, particularly with the added complexity around commits and pushes (trailing slashes, etc.) that I am sure my users are going to get wrong more often than right.

In further explorations, it occurred to me that the "subtree" merge strategy might be another, perhaps, better alternative. However, when I tried it based on the example at http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.ht ml, I got some results that were unexpected, such as files showing up where I didn't want them to: top-of-tree rather than the intended subdirectory.

Basically, I am starting out a project with x-loader, u-boot and linux based on the Arago project GIT at tag OMAPPSP_03.00.01.06, from which TI's somewhat-dated PSP is based:

    git://arago-project.org/git/projects/x-load-omap3.git
    git://arago-project.org/git/projects/u-boot-omap3.git
    git://arago-project.org/git/projects/linux-omap3.git

At some point, once my system is stable, I'd like to merge both u-boot and linux up to mainline revisions/tags with my local changes included from:

    git://git.denx.de/u-boot.git
    git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

My tree is organized roughly as:

    root/
        .git/
        fw/
            u-boot/
                Makefile
                u-boot/
                    <Actual contents of GIT tree here>
            x-loader/
                Makefile
                x-loader/
                    <Actual contents of GIT tree here>
        sw/
            tps/
                linux/
                    Makefile
                    linux/
                        <Actual contents of GIT tree here>

My ideal workflow would be:

    1) Merge Arago GIT git://arago-project.org/git/projects/u-boot-omap3.git
to root/fw/u-boot/u-boot/.
    2) Make local changes.
    3) % git commit ...
       % git push <to GitHub repo master>
    4) Make more local changes.
    5) % git commit ...
       % git push <to GitHub repo master>
    6) Ad infinitum until local changes are stable
    7) Merge Denx GIT git://git.denx.de/u-boot.git @ v2010.09-rc2 to
root/fw/u-boot/u-boot/.
       % git <something> ...
    8) Resolve conflicts, commit and push to GitHub repo master.

And so on for the linux subtree as well. Any further tips or course corrections you can offer, particularly relative to subtree merges?

Best,

Grant

On Sun, Sep 26, 2010 at 06:17:45PM -0700, Grant Erickson wrote:

*snip*

Unfortunately I'm not an expert here. I know what submodules do but I haven't used them much (in fact I last looked at them just after they were introduced. They were even rougher back then).

I may have missed it but if you haven't I'd update the list on all of this again.

--CJD

On 9/27/10 8:18 AM, Casey Dahlin wrote:

Casey:

Over the course of the weekend, I found a tool, braids, that does EXACTLY what I need. While it'd be great if it were integrated into GIT, I'll take it's external nature for now:

    http://github.com/evilchelu/braid

It would appear that in the background it uses the subtree merge strategy and a repository-local metadata files (.braids) to accomplish what it does.

Best,

Grant

Hi,

On Tue, Sep 21, 2010 at 9:22 AM, Grant Erickson <gerickson@nuovations.com> wrote:

Then be careful with the default remotes - for example, "origin", or branch-specific default remotes.