Question on GIT usage.

I have a kernel GIT tree to hold my developing patches...

I need to build this kernel for 4-5 different processors (c3, p2, p4, p4-smp, etc).

Is there any clever way to have this one git repository keep these other source trees in sync so that I can do incremental builds?

Should I perhaps have a unique git repo for each different build and just pull changes in from my master repo before building?

If there's a simple command to set up slave repositories like this, please point me to it.

Thanks!
Ben

Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com

There isn't, not really - but in the kernel's case, you don't need one, either.

Build with:

	make O=/path/to/c3/tree

Put your .config in /path/to/c3/tree/

All your compiled stuff will drop into that tree, and your source tree will stay untouched, so you can have a single GIT tree and source files.

Sounds like you just want to use a separate build directory for the kernel, which you can do quite independently of git (of course, not too many people use it, so the separate-object-directory Kbuild infrastructure has bugs every once in a while..)

The way it _should_ work is that you can do something like this:

.. have a clean source-tree in ~/src/linux ..

# set up the build tree
cd
mkdir build-tree
cd ~/src/linux
make O=~/build-tree oldconfig

# go there and build it
cd ~/build-tree
make

and now you can have a build-tree for each of your different architectures.

Now, you _can_ certainly do the very same thing with just multiple git repositories, and pull between them. That has its own set of advantages
too: you can have slight differences between the trees. Of course, if you know you don't want any differences between the trees, that's not an advantage, that's a disadvantage.

You can also have just one single real git repository, and then have that one checked out multiple times. Use GIT_OBJECT_DIRECTORY to share the core objects, and then you can have ten different git trees without duplicating all your objects and pack-files.

If you really want them 100%, the separate build trees is the best option.

That said, a lot of _other_ projects don't do separate build trees that well (and as mentioned, sometimes it breaks for the kernel too), and git certainly could be set up to be a "poor mans separate build tree".

Right now the easiest way to do that is to just have separate repositories (and share at least _some_ objects by just using "git clone -l -s" to clone them), but it could be hacked to be more geared explicitly towards that..

Linus

The following is not at all standard; AFAICT, I'm the only person who does it. But...

You can have a single repository shared between multiple working trees, by having the repository somewhere and making .git/{objects,refs,info,remotes} be symlinks to the corresponding directories in the repository. I've got a script to set this up, if you want.

The system will be unhappy if you commit to a branch that is checked out elsewhere (because the head of that branch will change out from under the checked out version), like having someone push to a repository with the branch checked out.

You need to think about this as there only being one repository that has multiple working trees, rather than having working tree/repository pairs, where the repositories are connected as an optimization; anything you do in one of the working trees will automatically affect what the others see.

This isn't official supported, but it actually works quite well, except that things that should be shared are occasionally added to the .git directory (like remotes not too long ago).

-Daniel
*This .sig left intentionally blank*

Well, the good news is that a "git checkout -f" in the other trees will do the right thing (and only check out the files that have changed).

The bad news is that you need to remember to do that ;)

Linus

If we wanted to make this work reliably, we could have a "LAST_CHECKED_OUT" which has an actual hash (rather than being a link like HEAD is), and gets set by the checkout. Then it would always know what commit you have checked out, even if something causes HEAD to not match.

I personally just never have the same branch checked out twice, so the situation doesn't happen to me. It's easy enough to add additional branches.

Oh, that reminds me: is there a simple way to merge a branch with another local branch or remote branch that's already up-to-date? E.g., I've already fetched the latest git from kernel.org, built it, and installed it. Now I want to merge my development branch with that. Last time I was looking, I had to write the message for the merge myself, unlike "pull", which takes care of that.

Also, I have a repository on my server for one of my projects. I push from my workstation to the "mainline" branch, and I have "deploy" checked out (with some configuration changes that shouldn't propagate back). Then I merge "mainline" into "deploy", build, and install. Same thing; I have to write the "merge with mainline" argument myself.

-Daniel
*This .sig left intentionally blank*

Umm.. Why don't you just use "pull"?

I _think_ you should be able to just do

git pull <repodir> <branchname>

where <repodir> can even be just "." for the very same repository.

I've not tested it, but dammit, it should work. If it doesn't, it's a bug.

Linus

I know it works. 'git pull . somebranch' is the command I use the second most often in the git suite (the first being git-show-branch).

That does follow logically, but it really ought to be an example in the documentation, because "fetch what you have from yourself and merge it" isn't the first thing that comes to mind for me. :)

I'll make sure that works and comes out nicely, and then send in a Documentation patch.

-Daniel
*This .sig left intentionally blank*