# git-bisect feature suggestion: "git-bisect diff" 36 messages from 2007-12-07 to 2007-12-12. Participants: Ingo Molnar, Junio C Hamano, Jeff King, Christian Couder, Pierre Habouzit, Jakub Narebski, Nicolas Pitre. Thread: https://gitlist.dev/t/11174 ## Ingo Molnar, 2007-12-07 09:34 Subject: git-bisect feature suggestion: "git-bisect diff" Message-ID: <20071207093439.GA21896@elte.hu> URL: https://gitlist.dev/e/20071207093439.GA21896%40elte.hu ``` would be nice to have: git-bisect diff that enables one to have a look at the currently open bisection window, in git-log -p format. This would often be much faster to analyze than looking at git-bisect visualize. (and it could also be used in non-GUI workflows) Right now i have this silly git-bisect-diff script: git-log -p "`git-bisect log | grep good | tail -1 | cut -d' ' -f3`".."\ `git-bisect log | grep bad | tail -1 | cut -d' ' -f3`" Ingo ``` ## Junio C Hamano, 2007-12-07 09:58 Subject: Re: git-bisect feature suggestion: "git-bisect diff" Message-ID: <7v63za4yic.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7v63za4yic.fsf%40gitster.siamese.dyndns.org In-Reply-To: <20071207093439.GA21896@elte.hu> ``` Ingo Molnar writes: > would be nice to have: > > git-bisect diff > > that enables one to have a look at the currently open bisection window, > in git-log -p format. This would often be much faster to analyze than > looking at git-bisect visualize. (and it could also be used in non-GUI > workflows) Hmm. It is very unfortunate that "bisect log" is taken for something unrelated, so tentatively let's call it lumber. $ git bisect lumber [-p] [--stat] would give you the short-hand, hopefully. --- git-bisect.sh | 12 +++++++++++- 1 files changed, 11 insertions(+), 1 deletions(-) diff --git a/git-bisect.sh b/git-bisect.sh index 7a6521e..ee26624 100755 --- a/git-bisect.sh +++ b/git-bisect.sh @@ -1,6 +1,6 @@ #!/bin/sh -USAGE='[start|bad|good|skip|next|reset|visualize|replay|log|run]' +USAGE='[start|bad|good|skip|next|reset|visualize|log|replay|lumber|run]' LONG_USAGE='git bisect start [ [...]] [--] [...] reset bisect state and start bisection. git bisect bad [] @@ -15,6 +15,8 @@ git bisect reset [] finish bisection search and go back to branch. git bisect visualize show bisect status in gitk. +git bisect lumber + show bisect status in git log. git bisect replay replay bisection log. git bisect log @@ -328,6 +330,12 @@ bisect_visualize() { eval gitk refs/bisect/bad --not $not -- $(cat "$GIT_DIR/BISECT_NAMES") } +bisect_lumber() { + bisect_next_check fail + not=$(git for-each-ref --format='%(refname)' "refs/bisect/good-*") + eval git log "$@" refs/bisect/bad --not $not -- $(cat "$GIT_DIR/BISECT_NAMES") +} + bisect_reset() { test -f "$GIT_DIR/BISECT_NAMES" || { echo "We are not bisecting." @@ -451,6 +459,8 @@ case "$#" in bisect_next "$@" ;; visualize) bisect_visualize "$@" ;; + lumber) + bisect_lumber "$@" ;; reset) bisect_reset "$@" ;; replay) ``` ## Junio C Hamano, 2007-12-07 10:25 Subject: Re: git-bisect feature suggestion: "git-bisect diff" Message-ID: <7vwsrq3iox.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vwsrq3iox.fsf%40gitster.siamese.dyndns.org In-Reply-To: <7v63za4yic.fsf@gitster.siamese.dyndns.org> ``` Junio C Hamano writes: > Ingo Molnar writes: > >> would be nice to have: >> >> git-bisect diff >> >> that enables one to have a look at the currently open bisection window, >> in git-log -p format. This would often be much faster to analyze than >> looking at git-bisect visualize. (and it could also be used in non-GUI >> workflows) > > Hmm. It is very unfortunate that "bisect log" is taken for something > unrelated, so tentatively let's call it lumber. > > $ git bisect lumber [-p] [--stat] > > would give you the short-hand, hopefully. More seriously... -- >8 -- git-bisect visualize: work in non-windowed environments better This teaches "git bisect visualize" to be more useful in non-windowed environments. (1) When no option is given, and $DISPLAY is set, it continues to spawn gitk as before; (2) When no option is given, and $DISPLAY is unset, "git log" is run to show the range of commits between the bad one and the good ones; (3) If only "-flag" options are given, "git log " is run. E.g. "git bisect visualize --stat" (4) Otherwise, all of the given options are taken as the initial part of the command line and the commit range expression is given to that command. E.g. "git bisect visualize tig" will run "tig" history viewer to show between the bad one and the good ones. As "visualize" is a bit too long to type, we also give it a shorter synonym "view". Signed-off-by: Junio C Hamano --- git-bisect.sh | 19 +++++++++++++++++-- 1 files changed, 17 insertions(+), 2 deletions(-) diff --git a/git-bisect.sh b/git-bisect.sh index 7a6521e..bb6fe84 100755 --- a/git-bisect.sh +++ b/git-bisect.sh @@ -324,8 +324,23 @@ bisect_next() { bisect_visualize() { bisect_next_check fail + + if test $# = 0 + then + case "${DISPLAY+set}" in + '') set git log ;; + set) set gitk ;; + esac + else + case "$1" in + git*|tig) ;; + -*) set git log "$@" ;; + *) set git "$@" ;; + esac + fi + not=$(git for-each-ref --format='%(refname)' "refs/bisect/good-*") - eval gitk refs/bisect/bad --not $not -- $(cat "$GIT_DIR/BISECT_NAMES") + eval '"$@"' refs/bisect/bad --not $not -- $(cat "$GIT_DIR/BISECT_NAMES") } bisect_reset() { @@ -449,7 +464,7 @@ case "$#" in next) # Not sure we want "next" at the UI level anymore. bisect_next "$@" ;; - visualize) + visualize|view) bisect_visualize "$@" ;; reset) bisect_reset "$@" ;; ``` ## Ingo Molnar, 2007-12-07 11:21 Subject: Re: git-bisect feature suggestion: "git-bisect diff" Message-ID: <20071207112159.GA11035@elte.hu> URL: https://gitlist.dev/e/20071207112159.GA11035%40elte.hu In-Reply-To: <7vwsrq3iox.fsf@gitster.siamese.dyndns.org> ``` * Junio C Hamano wrote: > (1) When no option is given, and $DISPLAY is set, it continues to > spawn gitk as before; > > (2) When no option is given, and $DISPLAY is unset, "git log" is run > to show the range of commits between the bad one and the good > ones; > > (3) If only "-flag" options are given, "git log " is run. > E.g. "git bisect visualize --stat" > > (4) Otherwise, all of the given options are taken as the initial part > of the command line and the commit range expression is given to > that command. E.g. "git bisect visualize tig" will run "tig" > history viewer to show between the bad one and the good ones. nice. One small detail though: i frequently ssh to testboxes that have DISPLAY set but i want text output. So git-bisect view --text should be a special-case perhaps? Ingo ``` ## Junio C Hamano, 2007-12-07 19:28 Subject: Re: git-bisect feature suggestion: "git-bisect diff" Message-ID: <7vmysm1eyz.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vmysm1eyz.fsf%40gitster.siamese.dyndns.org In-Reply-To: <20071207112159.GA11035@elte.hu> ``` Ingo Molnar writes: > ... One small detail though: i frequently ssh to testboxes that have > DISPLAY set but i want text output. So git-bisect view --text should be > a special-case perhaps? Yeah, but at that point, wouldn't "git bisect view log" be shorter to type? ``` ## Ingo Molnar, 2007-12-07 19:46 Subject: Re: git-bisect feature suggestion: "git-bisect diff" Message-ID: <20071207194630.GA11069@elte.hu> URL: https://gitlist.dev/e/20071207194630.GA11069%40elte.hu In-Reply-To: <7vmysm1eyz.fsf@gitster.siamese.dyndns.org> ``` * Junio C Hamano wrote: > Ingo Molnar writes: > > > ... One small detail though: i frequently ssh to testboxes that have > > DISPLAY set but i want text output. So git-bisect view --text should be > > a special-case perhaps? > > Yeah, but at that point, wouldn't "git bisect view log" be shorter to > type? it's also more intuitive. ok :-) Ingo ``` ## Jeff King, 2007-12-07 21:34 Subject: Re: git-bisect feature suggestion: "git-bisect diff" Message-ID: <20071207213414.GA11688@coredump.intra.peff.net> URL: https://gitlist.dev/e/20071207213414.GA11688%40coredump.intra.peff.net In-Reply-To: <7vwsrq3iox.fsf@gitster.siamese.dyndns.org> ``` On Fri, Dec 07, 2007 at 02:25:34AM -0800, Junio C Hamano wrote: > git-bisect visualize: work in non-windowed environments better Isn't this more or less the use case for the "git view" alias? diff --git a/git-bisect.sh b/git-bisect.sh index 7a6521e..3a21386 100755 --- a/git-bisect.sh +++ b/git-bisect.sh @@ -325,7 +325,7 @@ bisect_next() { bisect_visualize() { bisect_next_check fail not=$(git for-each-ref --format='%(refname)' "refs/bisect/good-*") - eval gitk refs/bisect/bad --not $not -- $(cat "$GIT_DIR/BISECT_NAMES") + eval git view refs/bisect/bad --not $not -- $(cat "$GIT_DIR/BISECT_NAMES") } bisect_reset() { ``` ## Jeff King, 2007-12-07 21:35 Subject: Re: git-bisect feature suggestion: "git-bisect diff" Message-ID: <20071207213541.GA11723@coredump.intra.peff.net> URL: https://gitlist.dev/e/20071207213541.GA11723%40coredump.intra.peff.net In-Reply-To: <20071207213414.GA11688@coredump.intra.peff.net> ``` On Fri, Dec 07, 2007 at 04:34:14PM -0500, Jeff King wrote: > On Fri, Dec 07, 2007 at 02:25:34AM -0800, Junio C Hamano wrote: > > > git-bisect visualize: work in non-windowed environments better > > Isn't this more or less the use case for the "git view" alias? Which isn't to say that I don't think your solution is nicer; it is. But if we don't use it here, then perhaps "git view" really is a solution in search of a problem. -Peff ``` ## Junio C Hamano, 2007-12-07 21:44 Subject: Re: git-bisect feature suggestion: "git-bisect diff" Message-ID: <7vtzmuyyc3.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vtzmuyyc3.fsf%40gitster.siamese.dyndns.org In-Reply-To: <20071207213541.GA11723@coredump.intra.peff.net> ``` Jeff King writes: > On Fri, Dec 07, 2007 at 04:34:14PM -0500, Jeff King wrote: > >> On Fri, Dec 07, 2007 at 02:25:34AM -0800, Junio C Hamano wrote: >> >> > git-bisect visualize: work in non-windowed environments better >> >> Isn't this more or less the use case for the "git view" alias? > > Which isn't to say that I don't think your solution is nicer; it is. But > if we don't use it here, then perhaps "git view" really is a solution in > search of a problem. Well, I think "git view" should not be just "predefined alias that the user can override wholesale", which is what you currently have. I think it can just be an example in "git config" manpage (i.e. "If you want to, you can alias 'view' to 'gitk' or 'gitview'") and I do not think we need core-side support for that. If it becomes cleverer, that's a different story. Noticing if the user is in windowing environment or not, and acting differently, would make it a single command that acts sensibly and in context sensitive way. ``` ## Jeff King, 2007-12-07 21:55 Subject: Re: git-bisect feature suggestion: "git-bisect diff" Message-ID: <20071207215514.GA11784@coredump.intra.peff.net> URL: https://gitlist.dev/e/20071207215514.GA11784%40coredump.intra.peff.net In-Reply-To: <7vtzmuyyc3.fsf@gitster.siamese.dyndns.org> ``` On Fri, Dec 07, 2007 at 01:44:12PM -0800, Junio C Hamano wrote: > Well, I think "git view" should not be just "predefined alias that the > user can override wholesale", which is what you currently have. I think > it can just be an example in "git config" manpage (i.e. "If you want to, > you can alias 'view' to 'gitk' or 'gitview'") and I do not think we need > core-side support for that. Sure, but regular aliases already do that. The point of making it a "builtin" alias is that we can depend on it being there. But who is depending? -Peff ``` ## Junio C Hamano, 2007-12-07 22:03 Subject: Re: git-bisect feature suggestion: "git-bisect diff" Message-ID: <7vprxiyxfj.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vprxiyxfj.fsf%40gitster.siamese.dyndns.org In-Reply-To: <20071207215514.GA11784@coredump.intra.peff.net> ``` Jeff King writes: > On Fri, Dec 07, 2007 at 01:44:12PM -0800, Junio C Hamano wrote: > >> Well, I think "git view" should not be just "predefined alias that the >> user can override wholesale", which is what you currently have. I think >> it can just be an example in "git config" manpage (i.e. "If you want to, >> you can alias 'view' to 'gitk' or 'gitview'") and I do not think we need >> core-side support for that. > > Sure, but regular aliases already do that. The point of making it a > "builtin" alias is that we can depend on it being there. But who is > depending? Nobody is depending. And I think the reason nobody depends on it is because there is no compelling reason to. Perhaps the behaviour is not useful enough. It surely is the case for "bisect view". ``` ## Jeff King, 2007-12-07 22:07 Subject: Re: git-bisect feature suggestion: "git-bisect diff" Message-ID: <20071207220738.GA23535@coredump.intra.peff.net> URL: https://gitlist.dev/e/20071207220738.GA23535%40coredump.intra.peff.net In-Reply-To: <7vprxiyxfj.fsf@gitster.siamese.dyndns.org> ``` On Fri, Dec 07, 2007 at 02:03:44PM -0800, Junio C Hamano wrote: > > Sure, but regular aliases already do that. The point of making it a > > "builtin" alias is that we can depend on it being there. But who is > > depending? > > Nobody is depending. > > And I think the reason nobody depends on it is because there is no > compelling reason to. Perhaps the behaviour is not useful enough. It > surely is the case for "bisect view". Right, which leads to my (perhaps subtle) point that the builtin alias hack is just what you said elsewhere: a cute hack. IOW, I am slightly NAKing inclusion of it in master (OTOH, I really don't see what it could _hurt_, so maybe somebody could find a use for it that we didn't think of). -Peff ``` ## Junio C Hamano, 2007-12-08 02:54 Subject: Re: git-bisect feature suggestion: "git-bisect diff" Message-ID: <7vabolzyjf.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vabolzyjf.fsf%40gitster.siamese.dyndns.org In-Reply-To: <20071207220738.GA23535@coredump.intra.peff.net> ``` Jeff King writes: > Right, which leads to my (perhaps subtle) point that the builtin alias > hack is just what you said elsewhere: a cute hack. IOW, I am slightly > NAKing inclusion of it in master (OTOH, I really don't see what it could > _hurt_, so maybe somebody could find a use for it that we didn't think > of). Heh, since when one can NAK one's own change? ;-) Yeah, I am inclined to let it rot in 'next' until 1.5.4 ships and then decide. Either people will forget about it (in which case we can revert) or enough people would want it and give some magic smarts to it. ``` ## Christian Couder, 2007-12-08 05:36 Subject: Re: git-bisect feature suggestion: "git-bisect diff" Message-ID: <200712080636.12982.chriscool@tuxfamily.org> URL: https://gitlist.dev/e/200712080636.12982.chriscool%40tuxfamily.org In-Reply-To: <20071207093439.GA21896@elte.hu> ``` Le vendredi 7 décembre 2007, Ingo Molnar a écrit : > would be nice to have: > > git-bisect diff > > that enables one to have a look at the currently open bisection window, > in git-log -p format. This would often be much faster to analyze than > looking at git-bisect visualize. (and it could also be used in non-GUI > workflows) > > Right now i have this silly git-bisect-diff script: > > git-log -p "`git-bisect log | grep good | tail -1 | cut -d' ' -f3`".."\ > `git-bisect log | grep bad | tail -1 | cut -d' ' -f3`" > Tell us if you have other scripts or suggestions related to git-bisect. And thanks for you kind word about it: http://thread.gmane.org/gmane.linux.kernel.input/3740/focus=3764 Christian. ``` ## Ingo Molnar, 2007-12-08 15:29 Subject: Re: git-bisect feature suggestion: "git-bisect diff" Message-ID: <20071208152922.GB30270@elte.hu> URL: https://gitlist.dev/e/20071208152922.GB30270%40elte.hu In-Reply-To: <200712080636.12982.chriscool@tuxfamily.org> ``` * Christian Couder wrote: > > Right now i have this silly git-bisect-diff script: > > > > git-log -p "`git-bisect log | grep good | tail -1 | cut -d' ' > > -f3`".."\ `git-bisect log | grep bad | tail -1 | cut -d' ' -f3`" > > > > Tell us if you have other scripts or suggestions related to > git-bisect. i have scripts around "git-bisect run" (which are custom to my test environment so not generally applicable), but perhaps it would be useful to extend it a little bit to have automatic support for "build error bisection". 99% of the FOSS packages that developed under git can be built via "make". So could you perhaps add fully automatic bisection support that is driven by doing "make" in the current repository? Currently, in the Linux kernel, if i do this: $ git-bisect run make -j64 kernel/ it fails with: running make -j64 kernel/ CHK include/linux/version.h CHK include/linux/utsrelease.h CALL scripts/checksyscalls.sh bisect run failed: bisect_good exited with error code 1 although the command "make -j64 kernel/" returns with 0. i have to write a script around "make -j64 kernel/" to get this to work - it would be nice to have this "out of box". Ingo ``` ## Christian Couder, 2007-12-09 05:33 Subject: git-bisect run make -j64 kernel/ (was Re: git-bisect feature suggestion: "git-bisect diff") Message-ID: <200712090633.36086.chriscool@tuxfamily.org> URL: https://gitlist.dev/e/200712090633.36086.chriscool%40tuxfamily.org In-Reply-To: <20071208152922.GB30270@elte.hu> ``` Le samedi 8 décembre 2007, Ingo Molnar a écrit : > Currently, in the Linux kernel, if i do this: > > $ git-bisect run make -j64 kernel/ > > it fails with: > > running make -j64 kernel/ > CHK include/linux/version.h > CHK include/linux/utsrelease.h > CALL scripts/checksyscalls.sh > bisect run failed: > bisect_good exited with error code 1 > > although the command "make -j64 kernel/" returns with 0. > > i have to write a script around "make -j64 kernel/" to get this to work > - it would be nice to have this "out of box". It seems to work for me. After creating a .config, I did: $ git bisect good v2.6.23 $ git bisect bad HEAD $ git bisect run make -j64 kernel/ Then I had to answer some configuration questions (I hit everytime) but it run fine. My git version is: git version 1.5.3.7.2200.g9275-dirty I attached the log (from git bisect log) and here is the end of the bisection: Bisecting: 74 revisions left to test after this [09f3eca2b7e2762e223fdd359f9d0f6303a85f6c] Merge branch 'for-2.6.24' of git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc running make -j64 kernel/ scripts/kconfig/conf -s arch/x86/Kconfig # # configuration written to .config # CHK include/linux/version.h CHK include/linux/utsrelease.h CC arch/x86/kernel/asm-offsets.s GEN include/asm-x86/asm-offsets.h CALL scripts/checksyscalls.sh CC kernel/sched.o CC kernel/fork.o CC kernel/panic.o CC kernel/printk.o CC kernel/profile.o CC kernel/exec_domain.o CC kernel/exit.o CC kernel/itimer.o CC kernel/time.o CC kernel/softirq.o CC kernel/resource.o CC kernel/sysctl.o CC kernel/capability.o CC kernel/ptrace.o CC kernel/timer.o CC kernel/user.o CC kernel/signal.o CC kernel/sys.o CC kernel/kmod.o CC kernel/user_namespace.o CC kernel/pid.o CC kernel/rcupdate.o CC kernel/workqueue.o CC kernel/params.o CC kernel/posix-timers.o CC kernel/kthread.o CC kernel/kfifo.o CC kernel/posix-cpu-timers.o CC kernel/mutex.o CC kernel/hrtimer.o CC kernel/rwsem.o CC kernel/latency.o CC kernel/nsproxy.o CC kernel/extable.o CC kernel/wait.o CC kernel/utsname.o CC kernel/notifier.o CC kernel/sysctl_check.o CC kernel/futex.o CC kernel/srcu.o CC kernel/irq/handle.o CC kernel/power/main.o CC kernel/power/pm.o CC kernel/time/timekeeping.o CC kernel/power/process.o CC kernel/irq/manage.o CC kernel/time/ntp.o CC kernel/irq/spurious.o CC kernel/time/jiffies.o CC kernel/time/clockevents.o CC kernel/time/timer_list.o CC kernel/time/tick-common.o CC kernel/rtmutex.o CC kernel/dma.o CC kernel/cpu.o CC kernel/power/console.o CC kernel/irq/resend.o CC kernel/power/poweroff.o CC kernel/irq/chip.o CC kernel/irq/devres.o CC kernel/time/clocksource.o CC kernel/time/tick-broadcast.o CC kernel/irq/proc.o CC kernel/irq/autoprobe.o CC kernel/irq/migration.o CC kernel/uid16.o CC kernel/spinlock.o CC kernel/module.o CC kernel/acct.o CC kernel/kexec.o CC kernel/stop_machine.o CC kernel/kallsyms.o CC kernel/audit.o CC kernel/auditfilter.o CC kernel/ksysfs.o kernel/power/pm.c:205: warning: 'pm_register' is deprecated (declared at kernel/power/pm.c:64) kernel/power/pm.c:205: warning: 'pm_register' is deprecated (declared at kernel/power/pm.c:64) kernel/power/pm.c:206: warning: 'pm_send_all' is deprecated (declared at kernel/power/pm.c:180) kernel/power/pm.c:206: warning: 'pm_send_all' is deprecated (declared at kernel/power/pm.c:180) CC kernel/utsname_sysctl.o LD kernel/power/built-in.o LD kernel/irq/built-in.o LD kernel/time/built-in.o LD kernel/built-in.o Bisecting: 38 revisions left to test after this [e17587b5b90da78f56c7a948e54dbac3dc791f31] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hskinnemoen/avr32-2.6 running make -j64 kernel/ CHK include/linux/version.h CHK include/linux/utsrelease.h CALL scripts/checksyscalls.sh Bisecting: 17 revisions left to test after this [c32bc6e9b0778c891f7f3b97cd05c8cdf98b6721] e1000: fix memcpy in e1000_get_strings running make -j64 kernel/ scripts/kconfig/conf -s arch/x86/Kconfig CHK include/linux/version.h CHK include/linux/utsrelease.h CALL scripts/checksyscalls.sh CC kernel/sched.o CC kernel/hrtimer.o CC kernel/time/clockevents.o LD kernel/time/built-in.o LD kernel/built-in.o Bisecting: 8 revisions left to test after this [4696c3c406a8b32112f8e1f70b3db1114950dcb1] ibm_newemac: Correct opb_bus_freq value running make -j64 kernel/ CHK include/linux/version.h CHK include/linux/utsrelease.h CALL scripts/checksyscalls.sh Bisecting: 4 revisions left to test after this [7962024e9d16e9349d76b553326f3fa7be64305e] S2io: Check for register initialization completion before accesing device registers running make -j64 kernel/ CHK include/linux/version.h CHK include/linux/utsrelease.h CALL scripts/checksyscalls.sh Bisecting: 2 revisions left to test after this [d1aa690a7d1afa673c3383bfcd6e96ddb350939a] ata_piix: add Toshiba Tecra M4 to broken suspend list running make -j64 kernel/ scripts/kconfig/conf -s arch/x86/Kconfig CHK include/linux/version.h CHK include/linux/utsrelease.h CALL scripts/checksyscalls.sh Bisecting: 1 revisions left to test after this [459ad68893a84fb0881e57919340b97edbbc3dc7] libata: kill spurious NCQ completion detection running make -j64 kernel/ CHK include/linux/version.h CHK include/linux/utsrelease.h CALL scripts/checksyscalls.sh 94545baded0bfbabdc30a3a4cb48b3db479dd6ef is first bad commit bisect run success It found the HEAD as the first bad commit as expected, because I had no compilation error. Christian. git-bisect start # good: [bbf25010f1a6b761914430f5fca081ec8c7accd1] Linux 2.6.23 git-bisect good bbf25010f1a6b761914430f5fca081ec8c7accd1 # bad: [94545baded0bfbabdc30a3a4cb48b3db479dd6ef] Merge branch 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev git-bisect bad 94545baded0bfbabdc30a3a4cb48b3db479dd6ef # good: [92d15c2ccbb3e31a3fc71ad28fdb55e1319383c0] Merge branch 'for-linus' of git://git.kernel.dk/data/git/linux-2.6-block git-bisect good 92d15c2ccbb3e31a3fc71ad28fdb55e1319383c0 # good: [c09b360a2b0779e08bacb88d3fcd8458ebc49658] Merge branch 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev git-bisect good c09b360a2b0779e08bacb88d3fcd8458ebc49658 # good: [6fa02839bf9412e18e773d04e96182b4cd0b5d57] nfsd4: recheck for secure ports in fh_verify git-bisect good 6fa02839bf9412e18e773d04e96182b4cd0b5d57 # good: [b5faa4b89e4d83203b1f44f143a351b518f7cda2] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/blackfin-2.6 git-bisect good b5faa4b89e4d83203b1f44f143a351b518f7cda2 # good: [c99da91e7a12724127475a85cc7a38214b3504e2] Merge branch 'master' into upstream-fixes git-bisect good c99da91e7a12724127475a85cc7a38214b3504e2 # good: [131b17d42de6194fa960132c1f62c29923c4f20c] spi: initial BF54x SPI support git-bisect good 131b17d42de6194fa960132c1f62c29923c4f20c # good: [09f3eca2b7e2762e223fdd359f9d0f6303a85f6c] Merge branch 'for-2.6.24' of git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc git-bisect good 09f3eca2b7e2762e223fdd359f9d0f6303a85f6c # good: [e17587b5b90da78f56c7a948e54dbac3dc791f31] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hskinnemoen/avr32-2.6 git-bisect good e17587b5b90da78f56c7a948e54dbac3dc791f31 # good: [c32bc6e9b0778c891f7f3b97cd05c8cdf98b6721] e1000: fix memcpy in e1000_get_strings git-bisect good c32bc6e9b0778c891f7f3b97cd05c8cdf98b6721 # good: [4696c3c406a8b32112f8e1f70b3db1114950dcb1] ibm_newemac: Correct opb_bus_freq value git-bisect good 4696c3c406a8b32112f8e1f70b3db1114950dcb1 # good: [7962024e9d16e9349d76b553326f3fa7be64305e] S2io: Check for register initialization completion before accesing device registers git-bisect good 7962024e9d16e9349d76b553326f3fa7be64305e # good: [d1aa690a7d1afa673c3383bfcd6e96ddb350939a] ata_piix: add Toshiba Tecra M4 to broken suspend list git-bisect good d1aa690a7d1afa673c3383bfcd6e96ddb350939a # good: [459ad68893a84fb0881e57919340b97edbbc3dc7] libata: kill spurious NCQ completion detection git-bisect good 459ad68893a84fb0881e57919340b97edbbc3dc7 ``` ## Ingo Molnar, 2007-12-11 09:24 Subject: Re: git-bisect feature suggestion: "git-bisect diff" Message-ID: <20071211092446.GA4703@elte.hu> URL: https://gitlist.dev/e/20071211092446.GA4703%40elte.hu In-Reply-To: <200712080636.12982.chriscool@tuxfamily.org> ``` * Christian Couder wrote: > Tell us if you have other scripts or suggestions related to > git-bisect. not strictly git-bisect related, but i've got the git-authors oneliner script below that i find very useful when figuring out whom to mail to related to a bug in any given kernel subsystem. For example when i see some USB problem i can do: git-authors v2.6.23.. drivers/usb/ which gives me the most active (and hence most relevant) developers in an area: 9 Pete Zaitcev 10 Inaky Perez-Gonzalez 12 David Brownell 12 Oliver Neukum 23 Alan Cox 49 Alan Stern with an email to pick up. In terms of accuracy this beats the MAINTAINERS file most of the time. And even when MAINTAINERS is accurate - in this particular case there are 48 'USB' related entries in the MAINTAINERS file - totally hard to sort out for a newbie. git-authors is also much easier and more natural to use - when i find problems it's usually related to a file, and i can run this: $ git-authors v2.6.23.. kernel/pid.c 1 Eric W. Biederman 1 Pavel Emelianov 1 Serge E. Hallyn 3 Sukadev Bhattiprolu 10 Pavel Emelyanov which works on a very finegrained level and gives a better "overview" than a pure git-log. Perhaps this could be a --authorstats option of git-log perhaps? Ingo ---------{ git-authors }---------> #!/bin/bash git-log $@ | grep Author: | cut -d: -f2 | sort | uniq -c | sort -n ``` ## Pierre Habouzit, 2007-12-11 09:29 Subject: Re: git-bisect feature suggestion: "git-bisect diff" Message-ID: <20071211092916.GF30948@artemis.madism.org> URL: https://gitlist.dev/e/20071211092916.GF30948%40artemis.madism.org In-Reply-To: <20071211092446.GA4703@elte.hu> ``` On Tue, Dec 11, 2007 at 09:24:46AM +0000, Ingo Molnar wrote: > ---------{ git-authors }---------> > #!/bin/bash > > git-log $@ | grep Author: | cut -d: -f2 | sort | uniq -c | sort -n You mean: git shortlog -n -s HEAD -- "$@" to do exactly the same right ? :) -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org ``` ## Jakub Narebski, 2007-12-11 10:13 Subject: Re: git-bisect feature suggestion: "git-bisect diff" Message-ID: URL: https://gitlist.dev/e/m3ve75sfn3.fsf%40roke.D-201 In-Reply-To: <20071211092916.GF30948@artemis.madism.org> ``` Pierre Habouzit writes: > On Tue, Dec 11, 2007 at 09:24:46AM +0000, Ingo Molnar wrote: > > ---------{ git-authors }---------> > > #!/bin/bash > > > > git-log $@ | grep Author: | cut -d: -f2 | sort | uniq -c | sort -n > > You mean: > git shortlog -n -s HEAD -- "$@" > to do exactly the same right ? :) Not exactly, as it does not give us email address. -- Jakub Narebski Poland ShadeHawk on #git ``` ## Ingo Molnar, 2007-12-11 10:17 Subject: Re: git-bisect feature suggestion: "git-bisect diff" Message-ID: <20071211101725.GB14372@elte.hu> URL: https://gitlist.dev/e/20071211101725.GB14372%40elte.hu In-Reply-To: <20071211092916.GF30948@artemis.madism.org> ``` * Pierre Habouzit wrote: > On Tue, Dec 11, 2007 at 09:24:46AM +0000, Ingo Molnar wrote: > > ---------{ git-authors }---------> > > #!/bin/bash > > > > git-log $@ | grep Author: | cut -d: -f2 | sort | uniq -c | sort -n > > You mean: > git shortlog -n -s HEAD -- "$@" > to do exactly the same right ? :) didnt know about that - i guess i wrote git-authors before even git-shortlog existed ;-) but i still prefer this format: 2 Serge E. Hallyn 10 Eric W. Biederman 10 Pavel Emelyanov 10 Sukadev Bhattiprolu because i'm not just interested in the stats, i'm also interested in an email address to pick. Also, the number should be the first column and aligned, it's easier to read for humans that way. (and this summary output is for humans.) Ingo ``` ## Pierre Habouzit, 2007-12-11 11:59 Subject: Re: git-bisect feature suggestion: "git-bisect diff" Message-ID: <20071211115914.GJ30948@artemis.madism.org> URL: https://gitlist.dev/e/20071211115914.GJ30948%40artemis.madism.org In-Reply-To: ``` On Tue, Dec 11, 2007 at 10:13:45AM +0000, Jakub Narebski wrote: > Pierre Habouzit writes: > > > On Tue, Dec 11, 2007 at 09:24:46AM +0000, Ingo Molnar wrote: > > > ---------{ git-authors }---------> > > > #!/bin/bash > > > > > > git-log $@ | grep Author: | cut -d: -f2 | sort | uniq -c | sort -n > > > > You mean: > > git shortlog -n -s HEAD -- "$@" > > to do exactly the same right ? :) > > Not exactly, as it does not give us email address. maybe it should be "fixed" so that it does, not to mention that other concerns ingo raised look legit to me. -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org ``` ## Jeff King, 2007-12-11 12:25 Subject: Re: git-bisect feature suggestion: "git-bisect diff" Message-ID: <20071211122539.GA13945@sigill.intra.peff.net> URL: https://gitlist.dev/e/20071211122539.GA13945%40sigill.intra.peff.net In-Reply-To: <20071211115914.GJ30948@artemis.madism.org> ``` On Tue, Dec 11, 2007 at 12:59:14PM +0100, Pierre Habouzit wrote: > > Not exactly, as it does not give us email address. > > maybe it should be "fixed" so that it does, not to mention that other > concerns ingo raised look legit to me. Perhaps Junio is a time-traveller. $ git show 4602c17d commit 4602c17d8911e14d537f6f87db02faab6e3f5d69 Author: Junio C Hamano Date: Fri Dec 7 17:19:31 2007 -0800 git-shortlog -e: show e-mail address as well This option shows the author's email address next to the name. Signed-off-by: Junio C Hamano ``` ## Jeff King, 2007-12-11 12:33 Subject: Re: git-bisect feature suggestion: "git-bisect diff" Message-ID: <20071211123312.GA14965@sigill.intra.peff.net> URL: https://gitlist.dev/e/20071211123312.GA14965%40sigill.intra.peff.net In-Reply-To: <20071211122539.GA13945@sigill.intra.peff.net> ``` On Tue, Dec 11, 2007 at 07:25:39AM -0500, Jeff King wrote: > $ git show 4602c17d > commit 4602c17d8911e14d537f6f87db02faab6e3f5d69 > Author: Junio C Hamano > Date: Fri Dec 7 17:19:31 2007 -0800 > > git-shortlog -e: show e-mail address as well > > This option shows the author's email address next to the name. > > Signed-off-by: Junio C Hamano And here is a matching documentation patch. I know, it's not a v1.5.4 bugfix, but hopefully it should be easy to review. ;) -- >8 -- shortlog: document -e option This was added in 4602c17d. Signed-off-by: Jeff King --- Documentation/git-shortlog.txt | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt index 2220ef6..e14720b 100644 --- a/Documentation/git-shortlog.txt +++ b/Documentation/git-shortlog.txt @@ -8,8 +8,8 @@ git-shortlog - Summarize 'git log' output SYNOPSIS -------- [verse] -git-log --pretty=short | 'git-shortlog' [-h] [-n] [-s] -git-shortlog [-n|--numbered] [-s|--summary] [...] +git-log --pretty=short | 'git-shortlog' [-h] [-n] [-s] [-e] +git-shortlog [-n|--numbered] [-s|--summary] [-e|--email] [...] DESCRIPTION ----------- @@ -32,6 +32,9 @@ OPTIONS -s, \--summary:: Suppress commit description and provide a commit count summary only. +-e, \--email:: + Show the email address of each author. + FILES ----- -- 1.5.3.7.2224.ge4a5 ``` ## Ingo Molnar, 2007-12-11 14:05 Subject: Re: git-bisect feature suggestion: "git-bisect diff" Message-ID: <20071211140508.GA12204@elte.hu> URL: https://gitlist.dev/e/20071211140508.GA12204%40elte.hu In-Reply-To: <20071211122539.GA13945@sigill.intra.peff.net> ``` * Jeff King wrote: > On Tue, Dec 11, 2007 at 12:59:14PM +0100, Pierre Habouzit wrote: > > > > Not exactly, as it does not give us email address. > > > > maybe it should be "fixed" so that it does, not to mention that other > > concerns ingo raised look legit to me. > > Perhaps Junio is a time-traveller. > > $ git show 4602c17d > commit 4602c17d8911e14d537f6f87db02faab6e3f5d69 > Author: Junio C Hamano > Date: Fri Dec 7 17:19:31 2007 -0800 > > git-shortlog -e: show e-mail address as well > > This option shows the author's email address next to the name. > > Signed-off-by: Junio C Hamano please switch around the column too so that the commit count comes first, this is way too ugly: Junio C Hamano: 4826 Shawn O. Pearce: 1146 Linus Torvalds: 950 Johannes Schindelin: 497 Eric Wong: 383 Jakub Narebski: 317 Simon Hausmann: 243 Nicolas Pitre: 235 Ingo ``` ## Pierre Habouzit, 2007-12-11 14:43 Subject: [PATCH] Invert numbers and names in the git-shortlog summary mode. Message-ID: <20071211144351.GA15448@artemis.madism.org> URL: https://gitlist.dev/e/20071211144351.GA15448%40artemis.madism.org In-Reply-To: <20071211140508.GA12204@elte.hu> ``` Also make it `cut` friendly using a tab to separate the numbers and names. Signed-off-by: Pierre Habouzit --- On Tue, Dec 11, 2007 at 02:05:08PM +0000, Ingo Molnar wrote: > please switch around the column too so that the commit count comes > first, this is way too ugly: > > Junio C Hamano: 4826 > Shawn O. Pearce: 1146 > Linus Torvalds: 950 [...] Agreed, here is the patch that does that, and a sample output is: $ git shortlog -n -s -e HEAD -- builtin-commit.c 11 Junio C Hamano 6 Johannes Schindelin 6 Kristian Høgsberg 2 Jeff King 1 Alex Riesen 1 Pierre Habouzit 1 Shawn Bohrer 1 Wincent Colaiuta builtin-shortlog.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/builtin-shortlog.c b/builtin-shortlog.c index 13df0c6..90666cb 100644 --- a/builtin-shortlog.c +++ b/builtin-shortlog.c @@ -265,7 +265,7 @@ int cmd_shortlog(int argc, const char **argv, const char *prefix) struct path_list *onelines = list.items[i].util; if (summary) { - printf("%s: %d\n", list.items[i].path, onelines->nr); + printf("%6d\t%s\n", onelines->nr, list.items[i].path); } else { printf("%s (%d):\n", list.items[i].path, onelines->nr); for (j = onelines->nr - 1; j >= 0; j--) { -- 1.5.3.7.2226.g8312-dirty ``` ## Ingo Molnar, 2007-12-11 14:57 Subject: Re: [PATCH] Invert numbers and names in the git-shortlog summary mode. Message-ID: <20071211145709.GB19427@elte.hu> URL: https://gitlist.dev/e/20071211145709.GB19427%40elte.hu In-Reply-To: <20071211144351.GA15448@artemis.madism.org> ``` * Pierre Habouzit wrote: > Agreed, here is the patch that does that, and a sample output is: > > $ git shortlog -n -s -e HEAD -- builtin-commit.c > 11 Junio C Hamano > 6 Johannes Schindelin > 6 Kristian Høgsberg > 2 Jeff King > 1 Alex Riesen > 1 Pierre Habouzit > 1 Shawn Bohrer > 1 Wincent Colaiuta great - this looks really neat! btw., stupid question: why are the git-shortlog command line arguments different from git-log? I got used to things like: git-log kernel/ so for me it would be natural to just do: git-shortlog -n -s kernel/ but this currently produces this output: $ git-shortlog -n -s kernel/ (reading log to summarize from standard input) which is quite a bit confusing to someone who'd like to keep as few details of command line arguments in his head as possible :-) Ingo ``` ## Pierre Habouzit, 2007-12-11 15:24 Subject: Re: [PATCH] Invert numbers and names in the git-shortlog summary mode. Message-ID: <20071211152412.GB15448@artemis.madism.org> URL: https://gitlist.dev/e/20071211152412.GB15448%40artemis.madism.org In-Reply-To: <20071211145709.GB19427@elte.hu> ``` On Tue, Dec 11, 2007 at 02:57:09PM +0000, Ingo Molnar wrote: > > * Pierre Habouzit wrote: > > > Agreed, here is the patch that does that, and a sample output is: > > > > $ git shortlog -n -s -e HEAD -- builtin-commit.c > > 11 Junio C Hamano > > 6 Johannes Schindelin > > 6 Kristian Høgsberg > > 2 Jeff King > > 1 Alex Riesen > > 1 Pierre Habouzit > > 1 Shawn Bohrer > > 1 Wincent Colaiuta > > great - this looks really neat! > > btw., stupid question: why are the git-shortlog command line arguments > different from git-log? I got used to things like: > > git-log kernel/ > > so for me it would be natural to just do: > > git-shortlog -n -s kernel/ > > but this currently produces this output: > > $ git-shortlog -n -s kernel/ > (reading log to summarize from standard input) > > which is quite a bit confusing to someone who'd like to keep as few > details of command line arguments in his head as possible :-) Because git-shortlog insists on you passing a reference first, HEAD is not implicit if you pass something that looks like a path first. This is arguably wrong. What you meant here is: $ git-shortlog -n -s HEAD kernel/ The reason IIRC is that git-shortlog once only read things on stdin, and this keeps backward compatbility to `git-shortlog` without any arguments. Sometimes history hurts :) I don't think there is much we can do on a short timescale. Maybe the old way can be slowly deprecated, and then git-shortlog will be able to act like git-log. -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org ``` ## Nicolas Pitre, 2007-12-11 15:34 Subject: Re: [PATCH] Invert numbers and names in the git-shortlog summary mode. Message-ID: URL: https://gitlist.dev/e/alpine.LFD.0.99999.0712111032530.555%40xanadu.home In-Reply-To: <20071211152412.GB15448@artemis.madism.org> ``` On Tue, 11 Dec 2007, Pierre Habouzit wrote: > On Tue, Dec 11, 2007 at 02:57:09PM +0000, Ingo Molnar wrote: > > > > * Pierre Habouzit wrote: > > > > > Agreed, here is the patch that does that, and a sample output is: > > > > > > $ git shortlog -n -s -e HEAD -- builtin-commit.c > > > 11 Junio C Hamano > > > 6 Johannes Schindelin > > > 6 Kristian Høgsberg > > > 2 Jeff King > > > 1 Alex Riesen > > > 1 Pierre Habouzit > > > 1 Shawn Bohrer > > > 1 Wincent Colaiuta > > > > great - this looks really neat! > > > > btw., stupid question: why are the git-shortlog command line arguments > > different from git-log? I got used to things like: > > > > git-log kernel/ > > > > so for me it would be natural to just do: > > > > git-shortlog -n -s kernel/ > > > > but this currently produces this output: > > > > $ git-shortlog -n -s kernel/ > > (reading log to summarize from standard input) > > > > which is quite a bit confusing to someone who'd like to keep as few > > details of command line arguments in his head as possible :-) > > Because git-shortlog insists on you passing a reference first, HEAD is > not implicit if you pass something that looks like a path first. This is > arguably wrong. What you meant here is: > > $ git-shortlog -n -s HEAD kernel/ > > The reason IIRC is that git-shortlog once only read things on stdin, and > this keeps backward compatbility to `git-shortlog` without any > arguments. > > Sometimes history hurts :) I don't think there is much we can do on a > short timescale. Maybe the old way can be slowly deprecated, and then > git-shortlog will be able to act like git-log. At least, HEAD could be assumed by default when stdin is a tty. Nicolas ``` ## Ingo Molnar, 2007-12-11 15:48 Subject: Re: [PATCH] Invert numbers and names in the git-shortlog summary mode. Message-ID: <20071211154841.GA29805@elte.hu> URL: https://gitlist.dev/e/20071211154841.GA29805%40elte.hu In-Reply-To: <20071211152412.GB15448@artemis.madism.org> ``` * Pierre Habouzit wrote: > > which is quite a bit confusing to someone who'd like to keep as few > > details of command line arguments in his head as possible :-) > > Because git-shortlog insists on you passing a reference first, HEAD is > not implicit if you pass something that looks like a path first. This > is arguably wrong. What you meant here is: > > $ git-shortlog -n -s HEAD kernel/ > > The reason IIRC is that git-shortlog once only read things on stdin, > and this keeps backward compatbility to `git-shortlog` without any > arguments. > > Sometimes history hurts :) I don't think there is much we can do on a > short timescale. Maybe the old way can be slowly deprecated, and then > git-shortlog will be able to act like git-log. if we are growing legacies in git this fast it will turn itself into CVS very quickly, give or take 20 years ;-) I think a straightforward usage model is paramount, so phasing out such inconsistencies as early as possible in the project's lifetime should be a priority IMHO. Git has a very, very 'refreshing' approach to information management, and that should permeate it all across. It's easy to be "fresh" in the beginning of a project - maintaining freshness for years is a lot harder. (i dont suggest to break compatibility, but to be aware of such inconsitencies and make it a priority to get rid of them. It does not help that such inconsistencies are only apparent to git newbies.) another thing i noticed that bites git newbies is that there are commands that do not do the "obvious" thing (to a newbie) and there are commands that just dont tell what they are doing. It would be very helpful if git was just a little bit more verbose about what it does. I.e. use the standard output for ... actual output, and there will be an instant and pleasant feedback loop between newbie and tool. It should basically "teach" the user along the way about what is being done, so that it quickly becomes an automatism. Especially where concepts differ from legacy SCMs. When is the index updated, when do files get modified, how branching works, etc. for example, if i type "git-checkout" in a Linux kernel tree, it just sits there for up to a minute, and "does nothing". That is totally wrong, human-interaction wise. Then after a minute it just returns. What happened? Why? Where? A newbie would then try "git-checkout -v", using the well-established "verbose" flag, but that gives: Usage: /usr/bin/git-checkout [-q] [-f] [-b ] [-m] [] [...] That's what a newbie asks. We are trying to turn the world of SCM's upside down with git, and we should do that by teaching things gradually and by being very explicit what happens and why, when a command is typed ;-) i could go on and on with other examples. (should I ? ;-) It's small, little details like that and if we fix a few dozen of them it will do _wonders_ to user education, really. The best tools are the ones that emit just about information to essentially give a tutorial to the newbie about the philosophy and workings of the tool - without being annoying to advanced users. It flattens the learning curve and increases adoption rate enormously. It also helps people learn their way out of the mental deformations that CVS causes ;-) And we could do this by adding a -q "quiet" flag, to restore the current 'silent' behavior of git. I could then do this in my .bashrc: alias git='git -q' to get the old, quiet behavior. This issue is pretty much the only conceptual advantage i can see of the competition like hg/mercurial ;-) Ok, enough ranting for today i guess =B-) Ingo ``` ## Pierre Habouzit, 2007-12-11 16:07 Subject: Re: [PATCH] Invert numbers and names in the git-shortlog summary mode. Message-ID: <20071211160744.GE15448@artemis.madism.org> URL: https://gitlist.dev/e/20071211160744.GE15448%40artemis.madism.org In-Reply-To: <20071211154841.GA29805@elte.hu> ``` On Tue, Dec 11, 2007 at 03:48:41PM +0000, Ingo Molnar wrote: > if we are growing legacies in git this fast it will turn itself into CVS > very quickly, give or take 20 years ;-) I think a straightforward usage > model is paramount, so phasing out such inconsistencies as early as > possible in the project's lifetime should be a priority IMHO. Git has a > very, very 'refreshing' approach to information management, and that > should permeate it all across. It's easy to be "fresh" in the beginning > of a project - maintaining freshness for years is a lot harder. (i dont > suggest to break compatibility, but to be aware of such inconsitencies > and make it a priority to get rid of them. It does not help that such > inconsistencies are only apparent to git newbies.) Well that's what deprecation is for, but you cannot do that on short timeframes. > for example, if i type "git-checkout" in a Linux kernel tree, it just > sits there for up to a minute, and "does nothing". That is totally > wrong, human-interaction wise. Then after a minute it just returns. What > happened? Why? Where? A newbie would then try "git-checkout -v", using > the well-established "verbose" flag, but that gives: > > Usage: /usr/bin/git-checkout [-q] [-f] [-b ] [-m] [] [...] not anymore: $ git checkout -v error: unknown switch `v' usage: git-branch [options] [] [...] -b ... create a new branch started at -l create the new branchs reflog --track tells if the new branch should track the remote branch -f proceed even if the index or working tree is not HEAD -m performa three-way merge on local modifications if needed -q, --quiet be quiet Not all commands are migrated to this new scheme though. The next git has a _lot_ of things done better wrt UI and such issues. Though some backward incompatible changes must be introduced with the proper deprecation warnings, so that people can adapt. -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org ``` ## Pierre Habouzit, 2007-12-11 16:11 Subject: Re: [PATCH] Invert numbers and names in the git-shortlog summary mode. Message-ID: <20071211161104.GG15448@artemis.madism.org> URL: https://gitlist.dev/e/20071211161104.GG15448%40artemis.madism.org In-Reply-To: <20071211160744.GE15448@artemis.madism.org> ``` On Tue, Dec 11, 2007 at 04:07:45PM +0000, Pierre Habouzit wrote: > On Tue, Dec 11, 2007 at 03:48:41PM +0000, Ingo Molnar wrote: > > if we are growing legacies in git this fast it will turn itself into CVS > > very quickly, give or take 20 years ;-) I think a straightforward usage > > model is paramount, so phasing out such inconsistencies as early as > > possible in the project's lifetime should be a priority IMHO. Git has a > > very, very 'refreshing' approach to information management, and that > > should permeate it all across. It's easy to be "fresh" in the beginning > > of a project - maintaining freshness for years is a lot harder. (i dont > > suggest to break compatibility, but to be aware of such inconsitencies > > and make it a priority to get rid of them. It does not help that such > > inconsistencies are only apparent to git newbies.) > > Well that's what deprecation is for, but you cannot do that on short > timeframes. > > > for example, if i type "git-checkout" in a Linux kernel tree, it just > > sits there for up to a minute, and "does nothing". That is totally > > wrong, human-interaction wise. Then after a minute it just returns. What > > happened? Why? Where? A newbie would then try "git-checkout -v", using > > the well-established "verbose" flag, but that gives: > > > > Usage: /usr/bin/git-checkout [-q] [-f] [-b ] [-m] [] [...] > > not anymore: > > $ git checkout -v > error: unknown switch `v' > usage: git-branch [options] [] [...] ^^^^^^ okay I felt stupid while reading this on list, a patch fixing this stupid lapsus has just been sent. Doh. -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org ``` ## Junio C Hamano, 2007-12-11 17:58 Subject: Re: [PATCH] Invert numbers and names in the git-shortlog summary mode. Message-ID: <7vzlwhdsgk.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vzlwhdsgk.fsf%40gitster.siamese.dyndns.org In-Reply-To: <20071211144351.GA15448@artemis.madism.org> ``` Pierre Habouzit writes: > Also make it `cut` friendly using a tab to separate the numbers and names. > > Signed-off-by: Pierre Habouzit > --- > > On Tue, Dec 11, 2007 at 02:05:08PM +0000, Ingo Molnar wrote: > > please switch around the column too so that the commit count comes > > first, this is way too ugly: > > > > Junio C Hamano: 4826 > > Shawn O. Pearce: 1146 > > Linus Torvalds: 950 > [...] > > Agreed, here is the patch that does that, and a sample output is: > > $ git shortlog -n -s -e HEAD -- builtin-commit.c > 11 Junio C Hamano > 6 Johannes Schindelin > 6 Kristian Høgsberg > 2 Jeff King > 1 Alex Riesen Thanks. Looks good. ``` ## Junio C Hamano, 2007-12-11 18:09 Subject: Re: [PATCH] Invert numbers and names in the git-shortlog summary mode. Message-ID: <7vr6htdry7.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vr6htdry7.fsf%40gitster.siamese.dyndns.org In-Reply-To: ``` Nicolas Pitre writes: > On Tue, 11 Dec 2007, Pierre Habouzit wrote: > ... >> Sometimes history hurts :) I don't think there is much we can do on a >> short timescale. Maybe the old way can be slowly deprecated, and then >> git-shortlog will be able to act like git-log. > > At least, HEAD could be assumed by default when stdin is a tty. I'd say I agree. -- >8 -- shortlog: default ot HEAD when standard input is a tty Instead of warning the user that it is expecting git log output from the standard input (and instructing to type the log from the keyboard), default to traverse from HEAD when there is no rev parameter given. This factors out a useful helper "add_head()" from builtin-diff.c to a more appropriate place revision.c while renaming it to more descriptive name add_head_to_pending(), as that is what the function is about. Signed-off-by: Junio C Hamano --- builtin-shortlog.c | 5 +++-- builtin-diff.c | 14 +------------- builtin-log.c | 5 +---- revision.c | 12 ++++++++++++ revision.h | 2 ++ 5 files changed, 19 insertions(+), 19 deletions(-) diff --git a/builtin-shortlog.c b/builtin-shortlog.c index 90666cb..3d8d709 100644 --- a/builtin-shortlog.c +++ b/builtin-shortlog.c @@ -249,9 +249,10 @@ int cmd_shortlog(int argc, const char **argv, const char *prefix) read_mailmap(&mailmap, ".mailmap", &common_repo_prefix); + /* assume HEAD if from a tty */ + if (!rev.pending.nr && isatty(0)) + add_head_to_pending(&rev); if (rev.pending.nr == 0) { - if (isatty(0)) - fprintf(stderr, "(reading log to summarize from standard input)\n"); read_from_stdin(&list); } else diff --git a/builtin-diff.c b/builtin-diff.c index 1b61599..55fb84c 100644 --- a/builtin-diff.c +++ b/builtin-diff.c @@ -176,18 +176,6 @@ static int builtin_diff_combined(struct rev_info *revs, return 0; } -void add_head(struct rev_info *revs) -{ - unsigned char sha1[20]; - struct object *obj; - if (get_sha1("HEAD", sha1)) - return; - obj = parse_object(sha1); - if (!obj) - return; - add_pending_object(revs, obj, "HEAD"); -} - static void refresh_index_quietly(void) { struct lock_file *lock_file; @@ -272,7 +260,7 @@ int cmd_diff(int argc, const char **argv, const char *prefix) if (!strcmp(arg, "--")) break; else if (!strcmp(arg, "--cached")) { - add_head(&rev); + add_head_to_pending(&rev); if (!rev.pending.nr) die("No HEAD commit to compare with (yet)"); break; diff --git a/builtin-log.c b/builtin-log.c index e1f1cf6..d375c9d 100644 --- a/builtin-log.c +++ b/builtin-log.c @@ -18,9 +18,6 @@ static int default_show_root = 1; static const char *fmt_patch_subject_prefix = "PATCH"; -/* this is in builtin-diff.c */ -void add_head(struct rev_info *revs); - static void add_name_decoration(const char *prefix, const char *name, struct object *obj) { int plen = strlen(prefix); @@ -746,7 +743,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix) * does not have. */ rev.pending.objects[0].item->flags |= UNINTERESTING; - add_head(&rev); + add_head_to_pending(&rev); } /* * Otherwise, it is "format-patch -22 HEAD", and/or diff --git a/revision.c b/revision.c index 2a59035..7e2f4f1 100644 --- a/revision.c +++ b/revision.c @@ -139,6 +139,18 @@ void add_pending_object(struct rev_info *revs, struct object *obj, const char *n add_pending_object_with_mode(revs, obj, name, S_IFINVALID); } +void add_head_to_pending(struct rev_info *revs) +{ + unsigned char sha1[20]; + struct object *obj; + if (get_sha1("HEAD", sha1)) + return; + obj = parse_object(sha1); + if (!obj) + return; + add_pending_object(revs, obj, "HEAD"); +} + static struct object *get_reference(struct rev_info *revs, const char *name, const unsigned char *sha1, unsigned int flags) { struct object *object; diff --git a/revision.h b/revision.h index 992e1e9..8572315 100644 --- a/revision.h +++ b/revision.h @@ -130,6 +130,8 @@ extern void add_object(struct object *obj, extern void add_pending_object(struct rev_info *revs, struct object *obj, const char *name); +extern void add_head_to_pending(struct rev_info *); + enum commit_action { commit_ignore, commit_show, ``` ## Ingo Molnar, 2007-12-11 21:13 Subject: Re: [PATCH] Invert numbers and names in the git-shortlog summary mode. Message-ID: <20071211211341.GB6902@elte.hu> URL: https://gitlist.dev/e/20071211211341.GB6902%40elte.hu In-Reply-To: <20071211160744.GE15448@artemis.madism.org> ``` * Pierre Habouzit wrote: > > for example, if i type "git-checkout" in a Linux kernel tree, it > > just sits there for up to a minute, and "does nothing". That is > > totally wrong, human-interaction wise. Then after a minute it just > > returns. What happened? Why? Where? A newbie would then try > > "git-checkout -v", using the well-established "verbose" flag, but > > that gives: > > > > Usage: /usr/bin/git-checkout [-q] [-f] [-b ] [-m] [] [...] > > not anymore: > > $ git checkout -v > error: unknown switch `v' > usage: git-branch [options] [] [...] > > -b ... create a new branch started at > -l create the new branchs reflog > --track tells if the new branch should track the remote branch > -f proceed even if the index or working tree is not HEAD > -m performa three-way merge on local modifications if needed > -q, --quiet be quiet > > Not all commands are migrated to this new scheme though. > > The next git has a _lot_ of things done better wrt UI and such issues. > Though some backward incompatible changes must be introduced with the > proper deprecation warnings, so that people can adapt. hey, cool! Just when i decide to complain about it, after 2 years of suffering, it's already fixed in the devel branch =;-) I'll post suggestions once i have tried out the next version. I'm happy that the git "first impression" that new users are getting (and the many pitfalls that they can fall into) is being actively reviewed and improved. It's i think the main barrier for git world dominance :-) Ingo ``` ## Junio C Hamano, 2007-12-11 22:21 Subject: Re: [PATCH] Invert numbers and names in the git-shortlog summary mode. Message-ID: <7vlk80dga6.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vlk80dga6.fsf%40gitster.siamese.dyndns.org In-Reply-To: <20071211211341.GB6902@elte.hu> ``` Ingo Molnar writes: > * Pierre Habouzit wrote: > >> The next git has a _lot_ of things done better wrt UI and such issues. >> Though some backward incompatible changes must be introduced with the >> proper deprecation warnings, so that people can adapt. > > hey, cool! Just when i decide to complain about it, after 2 years of > suffering, it's already fixed in the devel branch =;-) Heh, as I saw you post "diff --git" patches to the kernel mailing list and heard nothing from you for the last two years here, I naturally assumed you were one of the many people who were perfectly happy with git. Please direct more complaints to this list, not to the kernel list nor elsewhere ;-). ``` ## Ingo Molnar, 2007-12-12 09:43 Subject: Re: git-bisect run make -j64 kernel/ (was Re: git-bisect feature suggestion: "git-bisect diff") Message-ID: <20071212094326.GF18018@elte.hu> URL: https://gitlist.dev/e/20071212094326.GF18018%40elte.hu In-Reply-To: <200712090633.36086.chriscool@tuxfamily.org> ``` * Christian Couder wrote: > Le samedi 8 décembre 2007, Ingo Molnar a écrit : > > Currently, in the Linux kernel, if i do this: > > > > $ git-bisect run make -j64 kernel/ > > > > it fails with: > > > > running make -j64 kernel/ > > CHK include/linux/version.h > > CHK include/linux/utsrelease.h > > CALL scripts/checksyscalls.sh > > bisect run failed: > > bisect_good exited with error code 1 > > > > although the command "make -j64 kernel/" returns with 0. > > > > i have to write a script around "make -j64 kernel/" to get this to work > > - it would be nice to have this "out of box". > > It seems to work for me. After creating a .config, I did: > > $ git bisect good v2.6.23 > $ git bisect bad HEAD > $ git bisect run make -j64 kernel/ > > Then I had to answer some configuration questions (I hit everytime) > but it run fine. > > My git version is: > > git version 1.5.3.7.2200.g9275-dirty i've got: git-core-1.5.3.6-1.fc8, so it's fairly recent. I'll try this later and come back to you if there's still a problem. Ingo ```