Git and linux source

KansaiRobot · 12-16-2014, 08:27 PM

Hello and thanks always.

I have just recently started using Git. It was recommended by members of this forum and I find it quite impressive.

So far I have practiced with this very fine tutorial

http://rypress.com/tutorials/git/

So I know the concepts and what are they for. What for do we stage, or commit etc.

Now my question is the following:

I have to download the linux kernel and userland source code, configurate it with make menuconfig and later build it with make and get some image file to write on a microcontroller. I have done this without problem several times.

But I want to apply git to this. Now I have no idea what kind of files there are in the linux code. I imagine a lot of .c and .h and makefile files and maybe some other settings. Also I can see some documentation etc.

Ok ok the question:

which files should I stage and which should I ignore?

I imagine all the .c and .h and makefile etc, leaving out all the .o and generated files but how about the rest of them? There are a lot of files, should I stage one by one

or the whole directory I download first? (which will include documentation and stuff) and should I stage them after the menuconfig settings?

Thank you for all your comments and help

veerain · 12-17-2014, 05:50 AM

In your cloned git directory you have to run:

1) git checkout version-number

2) git will populate the directory with dirs and files

3) Then usual make menuconfig; make can be done

KansaiRobot · 12-17-2014, 06:16 PM

Thank you for your answer.

First, I am not cloning a repository. I downloaded a tar file with the code of the kernel and userland.
But I suppose what you are saying is that once I untar that file I should do git init and then after that do the menuconfig.

So Git ---> make menuconfig

and not the opposite, am I understanding you right?

Thanks a lot

astrogeek · 12-17-2014, 06:30 PM

Depends on what you are trying to accomplish with git.

I would suggest the following:

1. When you untar the source, in the top directory, do your git init
2. Edit .git/info/exclude and uncomment the *[ao] line so that you don't save binaries
3. Save an initial state: git add . then git commit -a
4. Then do your menuconfig and build, etc.
5. When you have a configuration you want to keep, stage and commit, maybe branch

John VV · 12-17-2014, 07:33 PM

all depends on what you want to do

building a NEW kernel and REPLACING!!! the one built FOR your OS and installed WITH YOUR PACKAGE MANAGER
is no easy task

yes you could do a very basic build
and will likely miss most of the drivers for your hardware

then you have to make suer your package manager dose NOT replace it
( if you end up with a working one --- not a 100% certainty on that ,)

think of it as
REPLACING YOUR BRAIN !!!

it really is not that simple

as to git
well "`git` over it "

it is nice but there are also
svn
cvs
bzr

KansaiRobot · 12-18-2014, 06:26 PM

Quote:

Originally Posted by astrogeek

Depends on what you are trying to accomplish with git.

I would suggest the following:

1. When you untar the source, in the top directory, do your git init
2. Edit .git/info/exclude and uncomment the *[ao] line so that you don't save binaries
3. Save an initial state: git add . then git commit -a
4. Then do your menuconfig and build, etc.
5. When you have a configuration you want to keep, stage and commit, maybe branch

Thank you. When I untar the source I end up with two directories: one for the kernel and one for the userland files. Then I have to make a symbolic link from the userland to the kernel and call it linux-3.x
I understand your steps above but to be clear:

On step 3, when I do git add I suppose I have to do this for the whole directories, right? I mean doing it file by file would be enormous!
(I suppose this also saves the symbolic link I created, is this so?)

On step 5, I have to stage only the files I change, and I suppose doing a git status will list me the files that menuconfig and make changed, am I right?

Thank you very much for your great help

KansaiRobot · 12-18-2014, 06:31 PM

Quote:

Originally Posted by John VV

all depends on what you want to do

building a NEW kernel and REPLACING!!! the one built FOR your OS and installed WITH YOUR PACKAGE MANAGER
is no easy task

yes you could do a very basic build
and will likely miss most of the drivers for your hardware

then you have to make suer your package manager dose NOT replace it
( if you end up with a working one --- not a 100% certainty on that ,)

think of it as
REPLACING YOUR BRAIN !!!

it really is not that simple

as to git
well "`git` over it "

it is nice but there are also
svn
cvs
bzr

Well thank you for your comment.
I am working with cross compilation so I build a system on my PC for a different architecture: Arm
On top of this, since this architecture is source- based and not package-based building and replacing the kernel and the userland is a requirement everytime (you can not build "on top of that"

I havent used versioning systems so far, Git was recommended by members of this forum. Quite neat so far.

astrogeek · 12-18-2014, 06:55 PM

Quote:

Originally Posted by KansaiRobot

Thank you. When I untar the source I end up with two directories: one for the kernel and one for the userland files. Then I have to make a symbolic link from the userland to the kernel and call it linux-3.x
I understand your steps above but to be clear:

On step 3, when I do git add I suppose I have to do this for the whole directories, right? I mean doing it file by file would be enormous!
(I suppose this also saves the symbolic link I created, is this so?)

On step 5, I have to stage only the files I change, and I suppose doing a git status will list me the files that menuconfig and make changed, am I right?

Thank you very much for your great help

You might want to create a top level directory to contain both the kernel and userland trees, then init your git there. If you do it with a symlink I don't think git follows that by default.

Yes, for step 3, in the top level directory simply...

Code:

git add . -A (This stages all changes including deletions, the purpose of '.')
git commit -a (Commits all the staged changes)

Same for step 5, git add . -a followed by git commit -a.

See man git-tag and man git-branch for the syntax for adding tags to commits and creating branches.

And always, git status will show you changed, staged and unstaged files.

KansaiRobot · 12-18-2014, 08:27 PM

Thank you very much. I understood your explanation. Just one thing

Quote:

If you do it with a symlink I don't think git follows that by default.

I will do it as you indicate. Put it all inside a top directory.
What I meant is I have:

Code:

--Top Level Directory-------Userland Directory   : (Here, symbolic link to kernel)
                     |                                                 /
                     |______Kernel Directory        <-----------------/

Those are the instructions on how to build what I require. So my question is, when I commit the Top Level Directory, will this also save the symlink?

Thanks a thousand

astrogeek · 12-19-2014, 03:24 AM

Quote:

Originally Posted by KansaiRobot

I will do it as you indicate. Put it all inside a top directory.
What I meant is I have:

Code:

--Top Level Directory-------Userland Directory   : (Here, symbolic link to kernel)
                     |                                                 /
                     |______Kernel Directory        <-----------------/

Those are the instructions on how to build what I require. So my question is, when I commit the Top Level Directory, will this also save the symlink?

I experimented a little with that but am not certain I have the definitive answer yet.

It will save the symlink, but it will not follow the symlink (i.e., it will not include files below the symlink). But I think it just saves the symlink as an empty file, not as a symlink.

There are some configs that affect handling of symlinks but I do not know them well enough to advise.