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

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

Ingo Molnar <mingo@elte.hu> writes:

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

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

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

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

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

Ingo Molnar <mingo@elte.hu> writes:

Yeah, but at that point, wouldn't "git bisect view log" be shorter to type?

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

it's also more intuitive. ok :-)

	Ingo

On Fri, Dec 07, 2007 at 02:25:34AM -0800, Junio C Hamano wrote:

Isn't this more or less the use case for the "git view" alias?

On Fri, Dec 07, 2007 at 04:34:14PM -0500, Jeff King wrote:

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

Jeff King <peff@peff.net> writes:

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.

On Fri, Dec 07, 2007 at 01:44:12PM -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?

-Peff

Jeff King <peff@peff.net> writes:

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

On Fri, Dec 07, 2007 at 02:03:44PM -0800, Junio C Hamano wrote:

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

Jeff King <peff@peff.net> writes:

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.

Le vendredi 7 décembre 2007, Ingo Molnar a écrit :

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.

* Christian Couder <chriscool@tuxfamily.org> wrote:

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

Le samedi 8 décembre 2007, Ingo Molnar a écrit :

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.

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

* Christian Couder <chriscool@tuxfamily.org> wrote:

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

* Christian Couder <chriscool@tuxfamily.org> wrote:

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

On Tue, Dec 11, 2007 at 09:24:46AM +0000, Ingo Molnar wrote:

You mean:
    git shortlog -n -s HEAD -- "$@"
to do exactly the same right ? :)

Pierre Habouzit <madcoder@debian.org> writes:

Not exactly, as it does not give us email address.

On Tue, Dec 11, 2007 at 10:13:45AM +0000, Jakub Narebski wrote:

  maybe it should be "fixed" so that it does, not to mention that other
concerns ingo raised look legit to me.

On Tue, Dec 11, 2007 at 12:59:14PM +0100, Pierre Habouzit wrote:

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>

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

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

* Jeff King <peff@peff.net> 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
 Johannes Schindelin: 497
 Eric Wong: 383
 Jakub Narebski: 317
 Simon Hausmann: 243
 Nicolas Pitre: 235

	Ingo

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

* Pierre Habouzit <madcoder@debian.org> wrote:

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

On Tue, Dec 11, 2007 at 02:57:09PM +0000, Ingo Molnar wrote:

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.

On Tue, 11 Dec 2007, Pierre Habouzit wrote:

At least, HEAD could be assumed by default when stdin is a tty.

Nicolas

Nicolas Pitre <nico@cam.org> writes:

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

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

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

On Tue, Dec 11, 2007 at 03:48:41PM +0000, Ingo Molnar wrote:

  Well that's what deprecation is for, but you cannot do that on short
timeframes.

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.

On Tue, Dec 11, 2007 at 04:07:45PM +0000, Pierre Habouzit wrote:

                 ^^^^^^
  okay I felt stupid while reading this on list, a patch fixing this
  stupid lapsus has just been sent. Doh.

* Pierre Habouzit <madcoder@debian.org> wrote:

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

Ingo Molnar <mingo@elte.hu> writes:

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 ;-).

Pierre Habouzit <madcoder@debian.org> writes:

Thanks.  Looks good.

* Pierre Habouzit <madcoder@debian.org> wrote:

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