git-bisect feature suggestion: "git-bisect diff"

git-bisect feature suggestion: "git-bisect diff"

[Ingo Molnar]

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

Re: git-bisect feature suggestion: "git-bisect diff"

[Junio C Hamano]

Ingo Molnar <mingo@elte.hu> 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 [<bad> [<good>...]] [--] [<pathspec>...]
         reset bisect state and start bisection.
 git bisect bad [<rev>]
@@ -15,6 +15,8 @@ git bisect reset [<branch>]
         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 <logfile>
         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)

Re: git-bisect feature suggestion: "git-bisect diff"

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Ingo Molnar <mingo@elte.hu> 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 <options>" 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 <gitster@pobox.com>
---
 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 "$@" ;;

Re: git-bisect feature suggestion: "git-bisect diff"

[Ingo Molnar]

* Junio C Hamano <gitster@pobox.com> 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 <options>" 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

Re: git-bisect feature suggestion: "git-bisect diff"

[Junio C Hamano]

Ingo Molnar <mingo@elte.hu> 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?

Re: git-bisect feature suggestion: "git-bisect diff"

[Ingo Molnar]

* Junio C Hamano <gitster@pobox.com> wrote:

> Ingo Molnar <mingo@elte.hu> 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

Re: git-bisect feature suggestion: "git-bisect diff"

[Jeff King]

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() {

Re: git-bisect feature suggestion: "git-bisect diff"

[Jeff King]

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

Re: git-bisect feature suggestion: "git-bisect diff"

[Junio C Hamano]

Jeff King <peff@peff.net> 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.

Re: git-bisect feature suggestion: "git-bisect diff"

[Jeff King]

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

Re: git-bisect feature suggestion: "git-bisect diff"

[Junio C Hamano]

Jeff King <peff@peff.net> 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".

Re: git-bisect feature suggestion: "git-bisect diff"

[Jeff King]

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

Re: git-bisect feature suggestion: "git-bisect diff"

[Junio C Hamano]

Jeff King <peff@peff.net> 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.

Re: git-bisect feature suggestion: "git-bisect diff"

[Christian Couder]

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.

Re: git-bisect feature suggestion: "git-bisect diff"

[Ingo Molnar]

* Christian Couder <chriscool@tuxfamily.org> 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

git-bisect run make -j64 kernel/ (was Re: git-bisect feature suggestion: "git-bisect diff")

[Christian Couder]

[-- Attachment #1: Type: text/plain, Size: 6388 bytes --]

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 <enter>  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.





[-- Attachment #2: make_j64_kernel_bisect.log --]
[-- Type: text/x-log, Size: 2576 bytes --]

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

Re: git-bisect feature suggestion: "git-bisect diff"

[Ingo Molnar]

* Christian Couder <chriscool@tuxfamily.org> 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 <zaitcev@redhat.com>
     10  Inaky Perez-Gonzalez <inaky@linux.intel.com>
     12  David Brownell <david-b@pacbell.net>
     12  Oliver Neukum <oliver@neukum.org>
     23  Alan Cox <alan@lxorguk.ukuu.org.uk>
     49  Alan Stern <stern@rowland.harvard.edu>

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 <ebiederm@xmission.com>
      1  Pavel Emelianov <xemul@openvz.org>
      1  Serge E. Hallyn <serue@us.ibm.com>
      3  Sukadev Bhattiprolu <sukadev@us.ibm.com>
     10  Pavel Emelyanov <xemul@openvz.org>

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

Re: git-bisect feature suggestion: "git-bisect diff"

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 453 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: git-bisect feature suggestion: "git-bisect diff"

[Jakub Narebski]

Pierre Habouzit <madcoder@debian.org> 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

Re: git-bisect feature suggestion: "git-bisect diff"

[Ingo Molnar]

* Pierre Habouzit <madcoder@debian.org> 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 <serue@us.ibm.com>
     10  Eric W. Biederman <ebiederm@xmission.com>
     10  Pavel Emelyanov <xemul@openvz.org>
     10  Sukadev Bhattiprolu <sukadev@us.ibm.com>

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

Re: git-bisect feature suggestion: "git-bisect diff"

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 780 bytes --]

On Tue, Dec 11, 2007 at 10:13:45AM +0000, Jakub Narebski wrote:
> Pierre Habouzit <madcoder@debian.org> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: git-bisect feature suggestion: "git-bisect diff"

[Jeff King]

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 <gitster@pobox.com>
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 <gitster@pobox.com>

Re: git-bisect feature suggestion: "git-bisect diff"

[Jeff King]

On Tue, Dec 11, 2007 at 07:25:39AM -0500, Jeff King wrote:

> $ git show 4602c17d
> commit 4602c17d8911e14d537f6f87db02faab6e3f5d69
> Author: Junio C Hamano <gitster@pobox.com>
> 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 <gitster@pobox.com>

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 <peff@peff.net>
---
 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] [<committish>...]
+git-log --pretty=short | 'git-shortlog' [-h] [-n] [-s] [-e]
+git-shortlog [-n|--numbered] [-s|--summary] [-e|--email] [<committish>...]
 
 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

Re: git-bisect feature suggestion: "git-bisect diff"

[Ingo Molnar]

* Jeff King <peff@peff.net> 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 <gitster@pobox.com>
> 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 <gitster@pobox.com>

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

[PATCH] Invert numbers and names in the git-shortlog summary mode.

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 1633 bytes --]

Also make it `cut` friendly using a tab to separate the numbers and names.

Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---

    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 <gitster@pobox.com>
             6	Johannes Schindelin <Johannes.Schindelin@gmx.de>
             6	Kristian Høgsberg <krh@redhat.com>
             2	Jeff King <peff@peff.net>
             1	Alex Riesen <raa.lkml@gmail.com>
             1	Pierre Habouzit <madcoder@debian.org>
             1	Shawn Bohrer <shawn.bohrer@gmail.com>
             1	Wincent Colaiuta <win@wincent.com>


 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


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Invert numbers and names in the git-shortlog summary mode.

[Ingo Molnar]

* Pierre Habouzit <madcoder@debian.org> 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 <gitster@pobox.com>
>              6	Johannes Schindelin <Johannes.Schindelin@gmx.de>
>              6	Kristian Høgsberg <krh@redhat.com>
>              2	Jeff King <peff@peff.net>
>              1	Alex Riesen <raa.lkml@gmail.com>
>              1	Pierre Habouzit <madcoder@debian.org>
>              1	Shawn Bohrer <shawn.bohrer@gmail.com>
>              1	Wincent Colaiuta <win@wincent.com>

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

Re: [PATCH] Invert numbers and names in the git-shortlog summary mode.

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 2023 bytes --]

On Tue, Dec 11, 2007 at 02:57:09PM +0000, Ingo Molnar wrote:
> 
> * Pierre Habouzit <madcoder@debian.org> 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 <gitster@pobox.com>
> >              6	Johannes Schindelin <Johannes.Schindelin@gmx.de>
> >              6	Kristian Høgsberg <krh@redhat.com>
> >              2	Jeff King <peff@peff.net>
> >              1	Alex Riesen <raa.lkml@gmail.com>
> >              1	Pierre Habouzit <madcoder@debian.org>
> >              1	Shawn Bohrer <shawn.bohrer@gmail.com>
> >              1	Wincent Colaiuta <win@wincent.com>
> 
> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Invert numbers and names in the git-shortlog summary mode.

[Nicolas Pitre]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2011 bytes --]

On Tue, 11 Dec 2007, Pierre Habouzit wrote:

> On Tue, Dec 11, 2007 at 02:57:09PM +0000, Ingo Molnar wrote:
> > 
> > * Pierre Habouzit <madcoder@debian.org> 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 <gitster@pobox.com>
> > >              6	Johannes Schindelin <Johannes.Schindelin@gmx.de>
> > >              6	Kristian Høgsberg <krh@redhat.com>
> > >              2	Jeff King <peff@peff.net>
> > >              1	Alex Riesen <raa.lkml@gmail.com>
> > >              1	Pierre Habouzit <madcoder@debian.org>
> > >              1	Shawn Bohrer <shawn.bohrer@gmail.com>
> > >              1	Wincent Colaiuta <win@wincent.com>
> > 
> > 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

Re: [PATCH] Invert numbers and names in the git-shortlog summary mode.

[Ingo Molnar]

* Pierre Habouzit <madcoder@debian.org> 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 <new_branch>] [-m] [<branch>] [<paths>...]

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

Re: [PATCH] Invert numbers and names in the git-shortlog summary mode.

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 2289 bytes --]

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 <new_branch>] [-m] [<branch>] [<paths>...]

not anymore:

    $ git checkout -v
    error: unknown switch `v'
    usage: git-branch [options] [<branch>] [<paths>...]

	-b ...                create a new branch started at <branch>
	-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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Invert numbers and names in the git-shortlog summary mode.

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 1894 bytes --]

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 <new_branch>] [-m] [<branch>] [<paths>...]
> 
> not anymore:
> 
>     $ git checkout -v
>     error: unknown switch `v'
>     usage: git-branch [options] [<branch>] [<paths>...]
                 ^^^^^^
  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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Invert numbers and names in the git-shortlog summary mode.

[Junio C Hamano]

Pierre Habouzit <madcoder@debian.org> writes:

> Also make it `cut` friendly using a tab to separate the numbers and names.
>
> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> ---
>
>     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 <gitster@pobox.com>
>              6	Johannes Schindelin <Johannes.Schindelin@gmx.de>
>              6	Kristian Høgsberg <krh@redhat.com>
>              2	Jeff King <peff@peff.net>
>              1	Alex Riesen <raa.lkml@gmail.com>

Thanks.  Looks good.

Re: [PATCH] Invert numbers and names in the git-shortlog summary mode.

[Junio C Hamano]

Nicolas Pitre <nico@cam.org> 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 <gitster@pobox.com>
---

 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,

Re: [PATCH] Invert numbers and names in the git-shortlog summary mode.

[Ingo Molnar]

* Pierre Habouzit <madcoder@debian.org> 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 <new_branch>] [-m] [<branch>] [<paths>...]
> 
> not anymore:
> 
>     $ git checkout -v
>     error: unknown switch `v'
>     usage: git-branch [options] [<branch>] [<paths>...]
> 
> 	-b ...                create a new branch started at <branch>
> 	-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

Re: [PATCH] Invert numbers and names in the git-shortlog summary mode.

[Junio C Hamano]

Ingo Molnar <mingo@elte.hu> writes:

> * Pierre Habouzit <madcoder@debian.org> 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 ;-).

Re: git-bisect feature suggestion: "git-bisect diff"

[しらいしななこ]

Quoting Jeff King <peff@peff.net>:

> 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 <gitster@pobox.com>
> 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 <gitster@pobox.com>

Or, Junio and Ingo are the same person ;-)

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

----------------------------------------------------------------------
Free pop3 email with a spam filter.
http://www.bluebottle.com/tag/5

Re: git-bisect run make -j64 kernel/ (was Re: git-bisect feature suggestion: "git-bisect diff")

[Ingo Molnar]

* Christian Couder <chriscool@tuxfamily.org> 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 <enter>  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