Hi,
for my Linux-kernel build-script I am searching for a reliable check
of getting the ***latest*** version.
This could be 'v3.x.y-stable' or 'v3.x.y-rcX'.
'git tag' seems to be fast, but not reliable.
'git log --oneline' is slow, but does the job.
For getting v3.x.y-stable this seems to work...
$ git tag | grep ^'v3.[0-9]*' | grep -v '\-rc' | sort --version-sort
v3.0
v3.1
v3.2
v3.3
v3.4
v3.5
v3.6
v3.7
v3.8
v3.9
v3.10
...but not when listing v3.x.y-rcX, too:
$ git tag | grep ^'v3.[0-9]*' | sort --version-sort | grep ^'v3.10'
v3.10
v3.10-rc1
v3.10-rc2
v3.10-rc3
v3.10-rc4
v3.10-rc5
v3.10-rc6
v3.10-rc7
I know that v3.10 > v3.10-rcX, but not 'git tag' or 'sort --version-sort' :-).
This seems from my poor sed/awk/grep skills to be the most reliable method...
$ time git log --oneline v3.0-rc1.. | grep 'Linux 3.' | awk '{ print
$3 }' | grep ^'3.[0-9]*' | head -1
3.10
real 0m10.024s
user 0m5.611s
sys 0m4.857s
...but is slow (even I take v3.0-rc1 as the 1st version-tag of
Linux-v3.x series).
Any improvements?
Thanks in advance.
Regards,
- Sedat -
for my Linux-kernel build-script I am searching for a reliable check
of getting the ***latest*** version.
$ git describe HEAD
If you want a sorted list of tags,
$ git for-each-ref --sort=taggerdate --format="%(refname:short)" refs/tags
Are you looking for something else?
On Tue, Jul 2, 2013 at 10:46 AM, Ramkumar Ramachandra
[off-list ref] wrote:
Sedat Dilek wrote:
quoted
for my Linux-kernel build-script I am searching for a reliable check
of getting the ***latest*** version.
$ git describe HEAD
If you want a sorted list of tags,
$ git for-each-ref --sort=taggerdate --format="%(refname:short)" refs/tags
Are you looking for something else?
Hi Ramukar,
Thanks for the quick answer!
Cool, this seems to keep version-chronology!
$ git for-each-ref --sort=taggerdate --format="%(refname:short)"
refs/tags | grep ^'v3.[0-9]*' | tail -1
v3.10
$ git for-each-ref --sort=taggerdate --format="%(refname:short)"
refs/tags | grep ^'next-[0-9]*' | tail -1
next-20130702
Another question if I may ask:
Sometimes I need to bisect a previous Linux-Next version.
What I am doing is to have the latest Linux-v3.x.y(-rcX) as stable base.
$ git checkout upstream
$ git checkout -b Linux-v3.10-rc7 v3.10-rc7
Afterwards I checkout the latest Linux-Next remote repository with all
its (new) tags (here: next-20130628)
$ git checkout -b Linux-Next-v20130628
$ git pull linux-next --tags next-20130628
How do I get the latest available linux-version in the downgraded
(current) Linux-Next local repository (example: I have parallelly
Linux-Next-v20130702 and Linux-Next-v20130628)?
If I have all -next tags merged-in, I will get always today's 'next-20130702'.
Due to my poor git skillz I do this manually for git-bisect sessions.
Thanks again, you helped me a lot with the above!
- Sedat -
Sometimes I need to bisect a previous Linux-Next version.
What I am doing is to have the latest Linux-v3.x.y(-rcX) as stable base.
$ git checkout upstream
$ git checkout -b Linux-v3.10-rc7 v3.10-rc7
Afterwards I checkout the latest Linux-Next remote repository with all
its (new) tags (here: next-20130628)
$ git checkout -b Linux-Next-v20130628
$ git pull linux-next --tags next-20130628
How do I get the latest available linux-version in the downgraded
(current) Linux-Next local repository (example: I have parallelly
Linux-Next-v20130702 and Linux-Next-v20130628)?
I'm not able to understand the question. I'm not sure why you're
creating branches from existing tags. You can easily do:
$ git bisect start @ v3.10-rc7
(@ is a synonym for HEAD in the latest git)
You can also fetch all tags:
$ git fetch --tags
and decide what to do with them later:
$ git merge next-20130628
In the process, next-20130628 hasn't changed: you can still use it as a
bisect endpoint.
If I have all -next tags merged-in, I will get always today's 'next-20130702'.
Due to my poor git skillz I do this manually for git-bisect sessions.
*scratches head*
Can you try rephrasing your question?
On Tue, Jul 2, 2013 at 1:06 PM, Ramkumar Ramachandra [off-list ref] wrote:
Sedat Dilek wrote:
quoted
Sometimes I need to bisect a previous Linux-Next version.
What I am doing is to have the latest Linux-v3.x.y(-rcX) as stable base.
$ git checkout upstream
$ git checkout -b Linux-v3.10-rc7 v3.10-rc7
Afterwards I checkout the latest Linux-Next remote repository with all
its (new) tags (here: next-20130628)
$ git checkout -b Linux-Next-v20130628
$ git pull linux-next --tags next-20130628
How do I get the latest available linux-version in the downgraded
(current) Linux-Next local repository (example: I have parallelly
Linux-Next-v20130702 and Linux-Next-v20130628)?
I'm not able to understand the question. I'm not sure why you're
creating branches from existing tags. You can easily do:
$ git bisect start @ v3.10-rc7
(@ is a synonym for HEAD in the latest git)
You can also fetch all tags:
$ git fetch --tags
and decide what to do with them later:
$ git merge next-20130628
In the process, next-20130628 hasn't changed: you can still use it as a
bisect endpoint.
quoted
If I have all -next tags merged-in, I will get always today's 'next-20130702'.
Due to my poor git skillz I do this manually for git-bisect sessions.
*scratches head*
Can you try rephrasing your question?
OK, I will try.
The base for my local Linux development GIT repository is the one from
Linus (aka upstream/mainline).
There-in I pull diverse Linux-next releases where I take its latest
Linux-upstream version as the new base.
EXAMPLES:
1. next-20130628 has its base as v3.10-rc7
2. next-20130702 has its base as v3.10
I am using always the version-tags for switching to a new local repo.
As said above I switch to the latest Linux-upstream version of the
corresponding -next and then pull in via '--tags' (see above).
Let's say I am on today's next-20130702 and switch back to my local
next-20130628 tree, the lastest version-tag available is always
'next-20130702'.
It could be my workflow is somewhere wrong.
Hope this is a bit enlightening.
Regards,
- Sedat -