Question on GIT usage.

Question on GIT usage.

[Ben Greear]

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 <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Question on GIT usage.

[Ryan Anderson]

[-- Attachment #1: Type: text/plain, Size: 846 bytes --]

Ben Greear wrote:
> 
> 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.

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: Question on GIT usage.

[Linus Torvalds]

On Fri, 28 Oct 2005, Ben Greear wrote:
> 
> 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).

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.

> 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?

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

Re: Question on GIT usage.

[Daniel Barkalow]

On Fri, 28 Oct 2005, Ben Greear wrote:

> 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?

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*

Re: Question on GIT usage.

[Linus Torvalds]

On Mon, 31 Oct 2005, Daniel Barkalow wrote:
> 
> 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.

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

Re: Question on GIT usage.

[Daniel Barkalow]

On Mon, 31 Oct 2005, Linus Torvalds wrote:

> On Mon, 31 Oct 2005, Daniel Barkalow wrote:
> > 
> > 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.
> 
> 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 ;)

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*

Re: Question on GIT usage.

[Linus Torvalds]

On Mon, 31 Oct 2005, Daniel Barkalow wrote:
> 
> 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.

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

Re: Question on GIT usage.

[Daniel Barkalow]

On Mon, 31 Oct 2005, Linus Torvalds wrote:

> On Mon, 31 Oct 2005, Daniel Barkalow wrote:
> > 
> > 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.
> 
> 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.

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*

Re: Question on GIT usage.

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> 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.

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).