On Aug 11 2017, Davide Cavallari <davide.cavall...@gmail.com> wrote:
> Please help me understand how this command works. There is one case in the
> linux kernel repository that puzzles me. Let's consider patch "drm/i915/
> execlists: Reset RING registers upon resume" . This patch was committed 641
> commits after version 4.8-rc2:
> ~$ git describe bafb2f7d4755bf1571bd5e9a03b97f3fc4fe69ae
> So I would expect to find it in version 4.8-rc3 and later versions.
> However, if I search for the tag that follows (and hence contains) that
> commit, I do not find version 4.8-rc3, nor version 4.8, nor version 4.9, but
> ~$ git describe --contains bafb2f7d4755bf1571bd5e9a03b97f3fc4fe69ae
> Why? Why not v4.8-rc3? This means that the patch has been included neither in
> v4.8 nor in v4.9, but only in version 4.10-rc1, right? Why so much time was
> needed, considering it was the 621st commit on top ov v4.8-rc2?
You have to ask that the maintainers of the drm subsystem. If you look
at commit 5481e27f6fd06b7cb902072e81d6b083db8155eb you see that the
branch containing the above commit was merged into a branch that follows
v4.9-rc2, which eventually was merged into v4.10-rc1.
> BTW, what are the numbers 154^2~44^2~178 that follow the tag name?
See git-rev-parse(1). '~N' means to go back N parents, ^N means to pick
parent N of a merge commit.
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."