Should the directory that github is cloned into be completely empty when switching between master and release branches?

For Developers
1

Hi

I've been building my own firmware for the Linksys WRT series using the trunk/release builds. I'm wanting to try and compile some master builds now as I've found a couple of bugs in the trunk builds.

Apart from the obvious commands to switch between the different branches and releases

git branch < >
git checkout < >

would there be any conflict having both branches in the same folder/directory on my PC? The command that I issue after selecting the branch is

./scripts/feeds update -a && ./scripts/feeds install -a

but I have recently been told that there is different repositories for the different builds, so again with the files already downloaded for the release build would selecting the master branch overwrite the release's?

Many thanks

Will

2

The "core" code and the packages from the "feeds" are different checkouts from different repos. I regularly switch between "release" and "master" branches in the same directory. I always run the ./scripts/feeds update and install steps on each switch. I have assumed that there might be different feed branches/HEADs for the different core branches, but haven't confirmed. I also make sure that I run make clean any time I switch branches.

3

check here, seems there was another (more up to date?).

re: the mamba fan, I am not seeing the cron facility not run the fan script at the 5 minute mark on the flash of a new image.

4

Cheers for that.

I've been using the

make clean download world
./scripts/feeds update -a && ./scripts/feeds install -a

commands for a while now and has been very successful when compiling. Do you know if the '.config' file can be also used between different repos or is it recommended to make fresh one?

5

They are definitely different between significantly different source-code points, even on the same branch.

./scripts/diffconfig.sh can capture the differences in a current .config and then be used to "seed" it later on (copy saved output to .config then run make menuconfig or the like).

You can also manage your config and files with the env script -- which sets up a git repo in ./env and symlinks .config and files there. You can use the script, or manage with branches and tags as you might want either with git directly in the env directory, or using the -C argument to refer to that directory if you aren't in it.

1 Like
6

So if I was to perfect a configuration based off the trunk branch, going through the normal GUI of 'make menuconfig' and then saving it as the normal '.config' file for example, and then run the command

./scripts/diffconfig.sh > output_filename

this removes all of the unnecessary lines from the normal '.config' file to only what is needed. Correct?

When I then change branch I simply copy or rename 'output_filename' to '.config' followed by

make defconfig

and this appends the contents of diffconfig ('output_filename') to the default configuration?

7

See diff config. Also useful just for setting aside a good build, so you can try out things and go back if not happy.