Perhaps you can help me just understand better the logic behind the builds.
Prior to every build I execute a "make clean", then I issue a "git pull" to pull down the latest changes to source. After that I update and install feeds, then last before I build I execute a make defconfig against my .config file.
What I am seeing is that the builds produced range from "current" to "snapshot", or even a "snaphot + x". For example, I build r3000. Then I do a git pull and 7 changes come down, so head is technically r3007. But my final build is labeled as r3000+7.
Can someone help explain to me what is happening here, and why/when builds reflect true head value, or current vs snapshot version?
'Current' was renamed to 'snapshot' to avoid any confusion on what type of build you are running.
The number after the plus sign indicates your local commits on top of upstream LEDE commits. E.g.: I have two patches applied on my own branch, and when I run
./scripts/.getver.sh
it shows $revision+2.
If your build is labeled as +7, it looks like you have a local tree and not just a clone of the upstream one.
So what should be the standard practice of refreshing/updating your initial git clone so that it's current, prior to a new build?
Obviously I will issue an initial git clone to pull the source down at whatever commit point it is when you setup your build env, and then from there should just issue git pulls to refresh it, no? Or do I need to wipe it all out and pull it down fresh every time in between builds? (Thus having to build my chain etc again every time). I think it's supposed to be easier than that.
If you look at the github you will see a number of changes by jow that will account for the snapshot/current naming, there is also a long thread about same. No big deal, a rose is a rose...
You have some changes as @Borromini stated, you can use git stash to set them aside. You can get things back if needed from the stash. Then just git pull. It depends on just what those changes are, if just mwlwifi versions, aint no big.
AHHH, so is that the key that has marked my git clone as unique. When I modify the mwlwifi Makefile to bring down the current driver, at that point I have now "deviated" from the main tree. Thus I would need to issue a git stash in order to clear that and move forward (as far as getting the standard snapshot head name, instead of head +)?
I did see jow's commits to change from current to snapshot, and that makes sense. But the snapshot+ was throwing me a bit, as it still had all the commits, just was named differently than I expected.
Makes sense guys, thank you so much! Teaching me to fish here
Happy to help. The cleanest way to work with local changes is create your own branch, and rebase that periodically. I'm a git novice, but rebasing seems the best way to handle this kind of thing: you apply your own changes, and when upstream pushes new stuff, git rebase rewinds your changes, pulls in everything that got added upstream, then applies your own changes again; if it breaks, you get informed, so you can fix stuff, but you don't lose your work.
What I am seeing is that the builds produced range from "current" to
"snapshot", or even a "snaphot + x". For example, I build r3000. Then I do a
git pull and 7 changes come down, so head is technically r3007. But my final
build is labeled as r3000+7.
git doesn't have revision numbers like r3000 internally, we are trying to fake
them to make people comforatable.
When you cloned things, it created a tag that the version you have is r3000, you
then have 7 new commits, so you are at tag+7, which creates the string r3000+7
this is only confusing because the tag is "r3000", if the tag was v16.12.0 and
you saw then pulled 7 commits, v16.12.0+7 would make a lot of sense.
This is one of the things that should get much better once there is actually a
release
Happy to help. The cleanest way to work with local changes is create your own
branch, and rebase that periodically. I'm a git novice, but rebasing seems the
best way to handle this kind of thing: you apply your own changes, and when
upstream pushes new stuff, git rebase rewinds your changes, pulls in
everything that got added upstream, then applies your own changes again; if it
breaks, you get informed, so you can fix stuff, but you don't lose your work.
Actually, the git recommended way is that you use multiple branches on your
local system.
on one branch you pull the upstream and don't do any development
on another branch you do your development
on a third branch, you merge your development and the upstream branches for
testing.
you can then throw the third branch away and recreate it if things go badly
enough, and you have the development branch unpolluted with upstream changes so
that when you post a pull request to include it, things are clean.
So branch one is not your main fork of project, but a branch of it? And if
wanting to do multiple PRs you would create 2 more branches for each PR?
each PR should be developed on it's own branch. You may end up submitting them
(or having them accepted) in any order, so they need to be as independent as
possible.
Then you have the need to test your work and make sure that it doesn't cause
problems when combined with what other people have been doing (or what you have
been doing in other PRs)
to do this testing, you create as many throw-away branches as needed to combine
all the development sources for testing. Depending on how independent your PRs
really are, this may just be one branch for everything you have.
The only time you should really need to rebase is if someone else has been doing
work in the same area that you have and their work has been accepted first. At
that point you need to reconcile your work with theirs. You could do a merge
and/or create another commit to fix things up, but it's cleaner to do a rebase
so that you can 'pretend' that all your work was done after the other person's
work was merged.
This concept of 'pretending' in your published work is an important one. When
you are doing development, you end up going down a lot of dead-ends, make a lot
of mistakes that you only catch later, etc. Publishing the entire, ugly history
doesn't help people understand the resulting changes very much, and it leaves a
lot of traps that people can fall into when they are debugging and try backing
out a commit.
do all your development, with all it's ugly history, on a private branch. Then
once you have your feature working, you can use interactive rebase to re-order
your patches, modify them, and in general re-write the history so that the
result looks like you never made a mistake and never went down a dead-end. This
both avoids trouble when people are troubleshooting, and it makes it much easier
for people to understand the changes (and it's not uncommon for this step to
lead to further improvements in the PR)
@dlang, Thanks for that, after your initial description I thought I might have been thinking about this wrong, but this is in-line with how I was beginning to think about the issue. @cybrnook, apologies for the tangent, @dlang post had piqued my curiosity as I have been investigating correct method of how to handle my posed query.
As you likely already know, even though this may not be in line directly with what I asked, it helps to paint a better picture for me not only for the naming conventions. But also the proper process to follow when promoting through to production and the N, N+1 cycles etc....
