![]() ![]() isn't it that your are constantly driving on the master branch? I am not very sure if we are on the same track. HEAD is now at 70255e3d62 OpenWrt v18.06.1: adjust config git log -oneline | head -n 3ħ0255e3d62 OpenWrt v18.06.1: adjust config defaultsĥeb055306f rpcd: update to latest git HEADĮ11df1eac6 openssl: update to version 1.0.2p If you want to create a new branch to retain commits you create, you mayĭo so (now or later) by using -b with the checkout command again. State without impacting any branches by performing another checkout. Resolving deltas: 100% (296538/296538), cd git fetch git tag git checkout v18.06.1Ĭhanges and commit them, and you can discard any commits you make in this Remote: Compressing objects: 100% (88/88), done. (just for fun, as there is no new information compared to the previous examples except the current tag). Just like the three examples above (about various 17.01 tags) show. How do I get the 18.06.1 of the openwrt branch? To achieve that, do not checkout the release tag "v17.01.1" but checkout the branch "lede-17.01": When compiling from branch HEAD, the later fixes in the main 17.01 source and in the feeds get included into the build. Similarly fixes made later to the 17.01 branch main sources do not get included.įor most users it is usually better to compile from the HEAD of the 17.01 branch instead of compiling the exact release like 17.01.1. Later fixes made to LuCI and packages will not get compiled into the firmware. LEDE v17.01.1: adjust config defaultsĤ8461b5abc LEDE v17.01.1: adjust config defaultsħeb58cf109 utils/f2fs-tools: Update to 1.8.0ġd76542cca busybox: add musl compatible nslookup replacementĦca5ccc620 kernel: update kernel 4.4 to 4.4.61Ĭhecking out the exact release locks also the feeds (packages, LuCI etc.) to the release moment. Remote: Total 42 (delta 27), reused 27 (delta 27), pack-reused 15 The advice is valid for the 17.01.1 release: $ git fetch -tags If you are going to add stuff to the build, you are likely better off from fetching directly from the release branch's (like lede-17.01) HEAD and building from that, so that you get also all the later bug fixes. In any case, fetching rc1/rc2/release sources is meant to create sources exactly matching the release. Those two files can be deleted, and then the build will again use "last git commit" based date & version. In practice that means that if the rc2 (and later) sources are fetched via git and then new private commits are added to repo, the build system will overlook those when calculating date & version, and will use the rc2 date and git version info for the build. Note to git users: the two files "version.date" and "version" in the buildroot root will also override the version and date from git commits. Those two files will provide the correct date and git version that will work also when the source has been fetched as. The tagging script has been modified for 17.01.0-rc2 to create and include "version.date" and "version" files along the sources. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |