Cloning OpenWrt 18.06.1 stable with git

Hello,
I'm writing you because I'm having problems in cloning the OpenWrt 18.06.1 stable repository with git.
I'm completely not an expert of git and github, being more towards the newbie side, and probably I'm missing something.

What I want to obtain is to get a local copy of OpenWrt 18.06.1 with git clone, that should be exactly the same as a zipped version of the OpenWrt 18.06.1 build system I downloaded few months ago, containing, inside the "version" file the following string:

r7258-5eb055306f

And inside "version.date":

1534405875

I actually built a complete project using this version and I probably have no time to port it and test it again on newer development versions, due to quite strict deadlines (but this will be considered in the future). However, I would really like to share the patches on Github together with a mirror of the stable OpenWrt 18.06.1 repository, for which, if I'm not wrong, I need first to git clone the proper branch onto my PC.

I tried doing:

git clone https://git.openwrt.org/openwrt/openwrt.git
cd openwrt
git checkout v18.06.1
./scripts/feeds update -a
./scripts/feeds install -a

But I can clearly see some differences with respect to what I was expecting: for instance, within the 18.06.1 version I used for my project, there was still no "iw-full" package, while inside the downloaded repository the package is there (together with some errors within my tested ".config" file); moreover, there is neither a "version" nor "version.date" file, which is present only when I use "git checkout" with an older version, for instance when using "git checkout v17.01.0".
The structure of "package/kernel/mac80211/." is a bit different too, as if an updated version was downloaded.

What should I do to correctly clone the stable repository? Am I missing something?

Thank you very much in advance!

git clone -b openwrt-18.06 https://github.com/openwrt/openwrt.git
cd openwrt
git reset --hard 5eb055306fc6e41c4dcbf397754e648303e11734

You'll also need to reset packages feeds separately

2 Likes

Thank you very much! This actually let me download the version I was looking for.
What is the git reset command doing exactly (I really need to delve more into git...)? Is it resetting the current local branch and working tree to the specific state of the version I used for my project, after converting "r7258" to the corresponding commit, thanks to "getver.sh"?
So, is 18.06.1 still being updated? Or is the 18.06.1 stable version, which is distributed on the OpenWrt website, always corresponding to "r7258"? I'm getting a bit confused about this...

Then, how can I reset the package feeds?

Thanks a lot in advance!

git reset will "rewind" your repo to whatever commit you tell it do, --hard just enforces it (don't care about any changes just do it) and its for your local repo. As you don't have write permissions you don't need to worry about doing anything bad to upstream repo. Svn kinda works the other way around, svn up -rXXXX download commits "to" revision XXXX. Very simplified but you get the idea.

18.06.1 is a release (snapshot) of the 18.06 branch, the 18.06-branch does get updates whichis what you would call 18.06.1+/18.06.2 or 18.06.1 with additional patches, it all depends on your point of view in that aspect.

I'm not sure if feeds are tracked in some way but it's the same idea although you probably need clone and reset manually and then run ./scripts/feeds update -i && ./scripts/feeds install -a

1 Like

That 5eb055306f is actually one commit before the actual v18.06.1 release commit and tag. Checking out the actual v18.06.1 tag commit would lock the feeds into place.
See in https://github.com/openwrt/openwrt/commit/70255e3d624cd393612069aae0a859d1acbbeeae how feeds.conf.default gets get locked into static place by specifying a commit.

Checking out 5eb055306f via reset will leave the feeds definitions as they are, so the feeds will get updated with later changes.

1 Like

That works quite ok to checkout the actual v18.06.1 release version. See below.
(note also how the feeds.conf.default show the lock to specific commits.)

perus@ub1810:/tmp$ git clone https://git.openwrt.org/openwrt/openwrt.git
Cloning into 'openwrt'...
remote: Enumerating objects: 450423, done.
remote: Counting objects: 100% (450423/450423), done.
remote: Compressing objects: 100% (122694/122694), done.
remote: Total 450423 (delta 310738), reused 447476 (delta 308555)
Receiving objects: 100% (450423/450423), 142.27 MiB | 10.54 MiB/s, done.
Resolving deltas: 100% (310738/310738), done.
perus@ub1810:/tmp$ cd openwrt
perus@ub1810:/tmp/openwrt$ git checkout v18.06.1
Note: checking out 'v18.06.1'.

You are in 'detached HEAD' state. 
...
HEAD is now at 70255e3d62 OpenWrt v18.06.1: adjust config defaults

perus@ub1810:/tmp/openwrt$ cat version
r7258-5eb055306f
perus@ub1810:/tmp/openwrt$ cat version.date 
1534405875

perus@ub1810:/tmp/openwrt$ cat feeds.conf.default 
src-git packages https://git.openwrt.org/feed/packages.git^35e0b737ab496f5b51e80079b0d8c9b442e223f5
src-git luci https://git.openwrt.org/project/luci.git^f64b1523447547032d5280fb0bcdde570f2ca913
...

I am not sure how you you have done earlier, but you may have somehow mixed the gradually progressing 18.06 stable branch and the static 18.06.1 release.
(e.g. "iw-full" has been backported to the 18.06 branch HEAD, but it is not yet the static 5-month old 18.06.1 release. So, seeing iw-full means that you are not at v18.06.1 )

Advice and explanations in

1 Like

So the version file doesn't actually track the correct version? :slight_smile:

yeah, chicken vs. egg. You can't know the commit hash before the commit has been made.

The release commit that sets all the release values and is tagged as v18.06.1 will set the version.date and version file based on the previous commit (but that previous commit does not lock the feeds etc.)

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=70255e3d624cd393612069aae0a859d1acbbeeae;hp=5eb055306fc6e41c4dcbf397754e648303e11734

1 Like

Thank you so much for your replies, that clarified all my doubts about cloning a static stable release!

I was finally able to properly clone the desired stable version of OpenWrt, by using again the commands:

git clone https://git.openwrt.org/openwrt/openwrt.git
cd openwrt
git checkout v18.06.1

I don't really know what I was doing before, but now it is correctly checking out the static 18.06.1 release and I don't see the additional, more recent, updates, anymore.

I was then able to add the patches I created for my project to the cloned local repository.
The problem is now that I'm unable to share the patches on GitHub, together with a mirror of the stable OpenWrt 18.06.1 repository, that was my original intention.
I tried doing:

git add *
git commit -m "Message"

The modifications seems to be correctly accepted: if I use "git log" I can clearly see them:

commit 7ae5fbf7ea66c4b124436892af182494debdbb7a
Author: ...
Date:   Tue Jan 1 15:52:44 2019 +0100

   Message

But when I try to push a mirror of the stable OpenWrt release + my patches, with:

git push --mirror https://github.com/username/OpenWrt-mirror.git

I'm actually getting a version, on my GitHub repository, with all the recent updates (including the ones involving ath79, which was not present in the static 18.06.1 release), and without any of the files that I added.

Do you know why? If I try to push without "--mirror", I'm getting instead an error:

fatal: You are not currently on a branch.
To push the history leading to the current (detached HEAD)
state now, use

    git push https://github.com/francescoraves483/OpenWrt-V2X.git HEAD:<name-of-remote-branch>

Do you know what I am missing and what I can do to obtain the desired result of having a mirror of the static release (if it is possible)?

Thank you very much in advance!

I think that you are overlooking the detached state of the v18.06.1 tag. The error message below is quite logical, as you are not on a branch, but locked to a specific commit.

Regarding your question below:

Depends a bit how / to whom you are trying to share your code.

One option, following to some extent the advice from diizzy, would be to

  • have a normal fork of openwrt git,
  • not checkout the v18.06.1 tag, but
  • checkout 18.06 branch in your fork and then reset into that tag commit 70255e3d6, and then branch off a new feature branch from that commit. You could then commit your stuff into that new branch, and anybody could then checkout that branch from your fork and would get 18.06.1 plus your code.

I made an example for you and added just one text file to v18.06.1 but otherwise the example-fr483 branch has 18.06.1 code including the feed definitions:
https://github.com/hnyman/openwrt/commits/example-fr483
https://github.com/hnyman/openwrt/tree/example-fr483

 2005  git branch
 2006  git checkout openwrt-18.06
 2007  git reset --hard 70255e3d6
 2008  git checkout -b example-fr483
 2009  git log --oneline | head -n 4 > example.txt
 2010  git add example.txt
 2011  git commit
 2012  git log --oneline | head -n 4 
 2013  git push -u origin example-fr483

Anybody could then get that via

git clone https://github.com/hnyman/openwrt.git
cd openwrt
git checkout example-fr483

And for sharing stuff, just remember that you can download any commit from Github by just adding .patch into end of the page.
My example for you is: https://github.com/hnyman/openwrt/commit/f1add4b25925b4e0f7f8c0c2a5034fd14d5e2c8d.patch
So anybody could also get the commits that way, if you share links.

2 Likes

I don't understand why you do the reset, I do avoid resets because it to often cause grief later on. I would do the following on a github fork:

git clone https://github.com/jan-kardell/openwrt.git
cd openwrt
git branch example-jan v18.06.1
git checkout example-jan
git log --oneline | head -n 4 > example.txt
git add example.txt
git commit
git push --set-upstream origin example-jan

Now the files in the new branch can be viewed at https://github.com/jan-kardell/openwrt/tree/example-jan
Of course the branch and checkout commands could be combined to git checkout -b example-jan v18.06.1. Note that git defaults may be slightly different depending on what linux distro you use.

2 Likes

There are many ways to do things with git.

Your way using the git branch branchname start-point notation for branch creation works and looks more polished than my example above :wink:

Thank you very much!
So, I couldn't push directly to origin master or to any other branch of the mirrored GitHub repository because I was actually in the detached state (in which the HEAD is continuously pointing to a specific commit, instead of the last one I was trying to push, which was not on any branch)? Is my understanding correct?

Following your suggestions and your examples on GitHub, I was finally able to obtain the desired result.
To resume, I actually used the following commands (following @jan reply, without doing the reset and using the v18.06.1 tag), after forking the "openwrt/operwrt" repository and renaming it:

git clone https://github.com/francescoraves483/OpenWrt-V2X
cd OpenWrt-V2X
git branch OpenWrt-V2X-18.06.1 v18.06.1
git checkout OpenWrt-V2X-18.06.1

Then, after adding and editing the needed files (I used "add -f" to add the "files" folder, with few custom files to be added to /root in the final OpenWrt image, which were otherwise ignored):

git add -f *
git commit -m "Integrate IEEE 802.11p features into OpenWrt 18.06.1"
git push -u origin OpenWrt-V2X-18.06.1

By setting "OpenWrt-V2X-18.06.1" as default branch in the forked repository, on GitHub, I'm now able to directly view this branch as soon as I visit "https://github.com/francescoraves483/OpenWrt-V2X", and I can get a local copy of it by simply using:
git clone https://github.com/francescoraves483/OpenWrt-V2X.git
without the need of checking out, as this seems to already put me in the correct branch.
This is exactly what I was looking for!

Thanks again!

1 Like

You should use "git rebase -i HEAD~2" in the branch (or actually a repo?? :wink: ) to squash the two commits together, so that there is not a short text docs fix commit after the initial commit. (and then "git push -f" to overwrite the previous commits with the combined one)

So far it is just your private repo, so overwriting git history makes things more polished for later usage.

Yes. You were not in a branch with a history, but in a floating detached state.

1 Like

Thank you very much! I just followed your suggestion to squash the two commits together :wink: