Re: strange result of `git describe` while bisecting
On Fri, Jun 12, 2015 at 03:17:40PM +0200, Andreas Schwab wrote: > Philippe De Muyter writes: > > > I am bisecting the kernel tree between v3.17 and v3.18, and 'git describe' > > is used by the kernel compilation process. Why do I get a version > > v3.17-rc7-1626-ga4b4a2b, that seems outside of [v3.17..v3.18] ? > > Because your are testing a side branch that is based on v3.17-rc7. > > 3.17-rc7 --- 3.17 --- 3.18 >\ / > \- * -/ >^ > You are here --^ Thank you Andreas Philippe -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
strange result of `git describe` while bisecting
Hi, I am bisecting the kernel tree between v3.17 and v3.18, and 'git describe' is used by the kernel compilation process. Why do I get a version v3.17-rc7-1626-ga4b4a2b, that seems outside of [v3.17..v3.18] ? To reproduce : git bisect start git bisect bad v3.18 git bisect good v3.17 Bisecting: 6197 revisions left to test after this (roughly 13 steps) [754c780953397dd5ee5191b7b3ca67e09088ce7a] Merge branch 'for-v3.18' of git://git.linaro.org/people/mszyprowski/linux-dma-mapping git describe v3.17-6163-g754c780 git bisect bad Bisecting: 3086 revisions left to test after this (roughly 12 steps) [4a4743e840d06a5772be7c21110807165c5b3c9f] Merge tag 'fixes-nc-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc git describe v3.17-3076-g4a4743e git bisect good Bisecting: 1506 revisions left to test after this (roughly 11 steps) [a4b4a2b7f98a45c71a906b1126cabea6446a9905] Merge tag 'master-2014-10-02' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next git describe v3.17-rc7-1626-ga4b4a2b Philippe -- Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: identical hashes on two branches, but holes in git log
On Thu, May 21, 2015 at 08:58:35PM +0100, Philip Oakley wrote: > From: "Philippe De Muyter" > To: "Junio C Hamano" > Cc: ; "Jeff King" ; "John Keeping" > > Sent: Thursday, May 21, 2015 8:15 AM > Subject: Re: identical hashes on two branches, but holes in git log > > >> On Tue, May 19, 2015 at 03:12:31PM -0700, Junio C Hamano wrote: >>> Philippe De Muyter writes: >>> >>> > On Tue, May 19, 2015 at 09:01:10AM -0700, Junio C Hamano wrote: >>> >> Philippe De Muyter writes: >>> >> >>> >> > Trying to understand, I have eventually done "git log" on my >> > >>> branch and >>> >> > on v3.15 with the following commands : >>> >> > >>> >> > git log v3.15 --full-history --decorate=short | grep '^commit' > >> >>> > /tmp/3.15.commits >>> >> > git log --full-history --decorate=short | grep '^commit' > >> > >>> /tmp/mybranch.commits >>> >> >>> >> Either >>> >> >>> >> git log --oneline v3.15..HEAD ;# show what I have not in >> theirs >>> >> >>> >> or >>> >> >>> >> gitk v3.15...HEAD ;# show our differences graphically >>> > >>> > This shows the commits in my branch starting from the most recent > >>> common point, >>> > thus my commits, but I see differences in the files not explained > by >>> my commits, >>> > but by the fact that many older commits (between v3.13 and v3.14) > are >>> missing on >>> > my branch, but still in both branches I have a commit called v3.14 > >>> with the >>> > same hash. Is that normal ? >>> >>> Sorry, cannot parse. Neither of the above would show files, so just >>> about the place where you start talking about "I see differences in >>> the files", you lost me. >> >> Look at the other part of the thread, with the discussion with Jeff and >> John >> >> The light has come, and what I understand is: >> >> don't trust the default (ordering) mode of 'git log' :( > > > Surely the question now should be "What should the man page say that would > have explained the default ordering mode in an understandable way, rather > than the current misunderstanding?". > > What 'ordering' were you 'trusting' (presuming) anyway? The current default > mode doesn't actually say anything about the order anyway (as you've > discovered). I have used 'git log' on the current 'master' branch of the linux kernel to find at which point in the history a commit - that I know is disruptive for my work and that I know by name because I have seen it passing on a mailing list - had been applied. 'git log -decorate=short' showed it happening between v3.14-rc1 and v3.14-rc2, but after git checkout v3.14 I did not find the effects of the commit in the files that should have been affected by the commit. I expected at least that a commit listed between two tags on the same branch was really applied to that branch between those two tags. Philippe > >> >> I surmise this happens only when 'git merge' has been used. >> > -- > Philip -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: identical hashes on two branches, but holes in git log
On Tue, May 19, 2015 at 03:12:31PM -0700, Junio C Hamano wrote: > Philippe De Muyter writes: > > > On Tue, May 19, 2015 at 09:01:10AM -0700, Junio C Hamano wrote: > >> Philippe De Muyter writes: > >> > >> > Trying to understand, I have eventually done "git log" on my branch and > >> > on v3.15 with the following commands : > >> > > >> > git log v3.15 --full-history --decorate=short | grep '^commit' > > >> > /tmp/3.15.commits > >> > git log --full-history --decorate=short | grep '^commit' > > >> > /tmp/mybranch.commits > >> > >> Either > >> > >> git log --oneline v3.15..HEAD ;# show what I have not in theirs > >> > >> or > >> > >> gitk v3.15...HEAD ;# show our differences graphically > > > > This shows the commits in my branch starting from the most recent common > > point, > > thus my commits, but I see differences in the files not explained by my > > commits, > > but by the fact that many older commits (between v3.13 and v3.14) are > > missing on > > my branch, but still in both branches I have a commit called v3.14 with the > > same hash. Is that normal ? > > Sorry, cannot parse. Neither of the above would show files, so just > about the place where you start talking about "I see differences in > the files", you lost me. Look at the other part of the thread, with the discussion with Jeff and John The light has come, and what I understand is: don't trust the default (ordering) mode of 'git log' :( I surmise this happens only when 'git merge' has been used. Philippe -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: identical hashes on two branches, but holes in git log
On Wed, May 20, 2015 at 12:18:15PM -0400, Jeff King wrote: > On Wed, May 20, 2015 at 04:12:38PM +0200, Philippe De Muyter wrote: > > > After reading the man page of 'git log', should --topo-order not be the > > default log order ? > > The problem with --topo-order is that it has to traverse all of the > commits before starting output. So: > > $ time git log | head -1 > commit 64fb1d0e975e92e012802d371e417266d6531676 > > real0m0.038s > user0m0.032s > sys 0m0.008s > > $ time git log --topo-order | head -1 > commit 64fb1d0e975e92e012802d371e417266d6531676 > > real0m4.247s > user0m4.140s > sys 0m0.108s > > -Peff So we trade correctness for speed :( Is there a way to set topo-order as the default log order via git config ? Is topo-order already implemented as starting with the default order followed by an ancestor check or does it switch immediately to topological sort ? Philippe -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: identical hashes on two branches, but holes in git log
Hi John, On Wed, May 20, 2015 at 02:25:34PM +0100, John Keeping wrote: > On Wed, May 20, 2015 at 03:13:59PM +0200, Philippe De Muyter wrote: > > My initial problem (still unresolved/unanswered) is that some commits > > that appeared between v3.14-rc1 and v3.14-rc2 (specifically > > 817c27a128e18aed840adc295f988e1656fed7d1) are present in v3.15, but not > > in my branch. > > > > I have just checked online the v3.14 version on > > > > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/arch/arm/boot/dts/imx6qdl.dtsi > > > > > > and I see also the same "problem": the commit removing 738 lines is in the > > log > > 817c27a128e18aed840adc295f988e1656fed7d1 > > "ARM: dts: imx6qdl: make pinctrl nodes board specific", > > but the v3.14 version of the file still contains the 738 removed line, > > and I see no commit restoring those lines. > > > > I do not understand why those 738 lines are still present in v3.14 although > > they were removed between v3.14-rc1 and v3.14-rc2 :( > > Commit 817c27a128e18aed840adc295f988e1656fed7d1 isn't in v3.14: > > $ git describe --contains 817c27a128e18aed840adc295f988e1656fed7d1 > v3.15-rc1~77^2~40^2~57 > > $ git tag --contains 817c27a128e18aed840adc295f988e1656fed7d1 > v3.15 > v3.15-rc1 > v3.15-rc2 > v3.15-rc3 > v3.15-rc4 > v3.15-rc5 > v3.15-rc6 > v3.15-rc7 > v3.15-rc8 > v3.15.1 > v3.15.10 > v3.15.2 > [snip later tags] > > However, the commit date of 817c27a128e18aed840adc295f988e1656fed7d1 is > between the dates of v3.14-rc1 and v3.14-rc2 so the default commit > ordering of `git log` will show it between those two tags. > `--topo-order` may help but I suspect the history is too complex to > infer the relationship between commits without `--graph`. OK and Thanks. You saved me. I began to think I was going mad or there was a bug in git. After reading the man page of 'git log', should --topo-order not be the default log order ? Philippe -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
