What's cooking in git.git (Aug 2009, #02; Wed, 12)

What's cooking in git.git (Aug 2009, #02; Wed, 12)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'.  The ones
marked with '.' do not appear in any of the branches, but I am still
holding onto them.

After the 1.6.5 cycle, the next release will be 1.7.0, and we will push
out the planned "push safety" change.  1.7.0 would be a good time to
introduce "justifiable" changes that are not strictly backward compatible.

During 1.6.5 cycle, 'next' will hold topics meant for 1.6.5 and 1.7.0.

----------------------------------------------------------------
[New Topics]

* ld/p4 (Thu Jul 30 00:13:46 2009 +0100) 1 commit
 - git-p4: stream from perforce to speed up clones

Waiting for Ack/Nack from stakeholders.  Probably I should merge this to
'next' soon, keep it there for a week and see if anybody screams, aka
"Nack now or forever hold your peace" ;-).

* mr/gitweb-xz (Thu Aug 6 10:28:25 2009 -0400) 3 commits
 - gitweb: add support for XZ compressed snapshots
 - gitweb: update INSTALL regarding specific snapshot settings
 - gitweb: support to globally disable a snapshot format

This should be safe as long as it does not silently enable itself for
folks who merely updated gitweb to this version without explicitly asking
for the new format (but I do not remember if that is what the patch does).

* jh/cvs-helper (Wed Aug 12 02:13:51 2009 +0200) 4 commits
 - Add simple selftests of git-remote-cvs functionality
 - Third draft of CVS remote helper program
 - Add Python support library for CVS remote helper
 - Basic build infrastructure for Python scripts

Builds on db/vcs-helper.  The last round failed its own selftest for me,
but this one seems to be Ok.  Documentation/git-remote-cvs.txt needs to be
fixed to build, though.

* bc/maint-am-email (Thu Aug 6 20:08:13 2009 -0500) 2 commits
 + git-am: print fair error message when format detection fails
 + am: allow individual e-mail files as input

It seems that the "not mbox but a single piece of e-mail" format was
something many people relied on.  I'm cooking this in 'next', and
hopefully it can graduate both to 'master' and 'maint'.

* js/maint-cover-letter-non-ascii (Mon Aug 10 18:22:22 2009 +0200) 2 commits
 + Correctly mark cover letters' encodings if they are not pure ASCII
 + Expose the has_non_ascii() function

* jc/verify-pack-stat (Fri Aug 7 15:45:30 2009 -0700) 2 commits
 + verify-pack --stat-only: show histogram without verifying
 + Merge branch 'maint' into jc/verify-pack-stat

* lt/block-sha1 (Wed Aug 12 15:47:55 2009 -0400) 15 commits
 + block-sha1: support for architectures with memory alignment
   restrictions
 + block-sha1: split the different "hacks" to be individually
   selected
 + block-sha1: move code around
 + block-sha1: improve code on large-register-set machines
 + block-sha1: improved SHA1 hashing
 + block-sha1: perform register rotation using cpp
 + block-sha1: get rid of redundant 'lenW' context
 + block-sha1: Use '(B&C)+(D&(B^C))' instead of '(B&C)|(D&(B|C))' in
   round 3
 + block-sha1: macroize the rounds a bit further
 + block-sha1: re-use the temporary array as we calculate the SHA1
 + block-sha1: make the 'ntohl()' part of the first SHA1 loop
 + block-sha1: minor fixups
 + block-sha1: try to use rol/ror appropriately
 + block-sha1: undo ctx->size change
 + Add new optimized C 'block-sha1' routines

Linus's "written in C, faster than handcrafted asm" SHA-1 implementation
with clean-up and ARM support from Nico.

* nd/sparse (Tue Aug 11 22:44:06 2009 +0700) 8 commits
 . --sparse for porcelains
 . Support sparse checkout in unpack_trees() and read-tree
 . unpack-trees.c: generalize verify_* functions
 . dir.c: export excluded_1() and add_excludes_from_file_1()
 . excluded_1(): support exclude "directories" in index
 . Read .gitignore from index if it is assume-unchanged
 . Avoid writing to buffer in add_excludes_from_file_1()
 . Prevent diff machinery from examining assume-unchanged entries on
   worktree

Privately applied but not yet queued to 'pu', expecting a minor reroll
near the tip.

* jk/maint-merge-msg-fix (Sun Aug 9 06:02:51 2009 -0400) 3 commits
 + merge: indicate remote tracking branches in merge message
 + merge: fix incorrect merge message for ambiguous tag/branch
 + add tests for merge message headings

----------------------------------------------------------------
[Graduated to "master"]

* zf/maint-gitweb-acname (Sun Aug 2 09:42:24 2009 +0200) 1 commit
 - gitweb: parse_commit_text encoding fix

* jc/maint-merge-recursive-fix (Thu Jul 30 17:38:15 2009 -0700) 1 commit
 - merge-recursive: don't segfault while handling rename clashes

* js/run-command-updates (Tue Aug 4 11:28:40 2009 +0200) 7 commits
 + run-command.c: squelch a "use before assignment" warning
 + receive-pack: remove unnecessary run_status report
 + run_command: report failure to execute the program, but optionally
   don't
 + run_command: encode deadly signal number in the return value
 + run_command: report system call errors instead of returning error
   codes
 + run_command: return exit code as positive value
 + MinGW: simplify waitpid() emulation macros

* mk/grep-max-depth (Wed Jul 22 19:52:15 2009 +0200) 1 commit
 + grep: Add --max-depth option.

* jp/symlink-dirs (Wed Jul 29 20:22:25 2009 -0700) 3 commits
 + git-checkout: be careful about untracked symlinks
 + lstat_cache: guard against full match of length of 'name'
   parameter
 + Demonstrate bugs when a directory is replaced with a symlink

----------------------------------------------------------------
[In 'next']

* bc/mailsplit-cr-at-eol (Tue Aug 4 22:31:59 2009 -0500) 4 commits
 + Allow mailsplit (and hence git-am) to handle mails with CRLF line-
   endings
 + builtin-mailsplit.c: remove read_line_with_nul() since it is no
   longer used
 + builtin-mailinfo,builtin-mailsplit: use strbufs
 + strbuf: add new function strbuf_getwholeline()

* gb/apply-ignore-whitespace (Tue Aug 4 13:16:49 2009 +0200) 1 commit
 + git apply: option to ignore whitespace differences

* cc/replace (Wed May 27 07:14:09 2009 +0200) 14 commits
 + t6050: check pushing something based on a replaced commit
 + Documentation: add documentation for "git replace"
 + Add git-replace to .gitignore
 + builtin-replace: use "usage_msg_opt" to give better error messages
 + parse-options: add new function "usage_msg_opt"
 + builtin-replace: teach "git replace" to actually replace
 + Add new "git replace" command
 + environment: add global variable to disable replacement
 + mktag: call "check_sha1_signature" with the replacement sha1
 + replace_object: add a test case
 + object: call "check_sha1_signature" with the replacement sha1
 + sha1_file: add a "read_sha1_file_repl" function
 + replace_object: add mechanism to replace objects found in
   "refs/replace/"
 + refs: add a "for_each_replace_ref" function

* jc/1.7.0-diff-whitespace-only-status (Sat May 23 01:15:35 2009 -0700) 2 commits
 + diff: Rename QUIET internal option to QUICK
 + diff: change semantics of "ignore whitespace" options

This changes exit code from "git diff --ignore-whitespace" and friends
when there is no actual output.  It is a backward incompatible change, but
we could argue that it is a bugfix.

* jc/1.7.0-push-safety (Mon Feb 9 00:19:46 2009 -0800) 2 commits
 + Refuse deleting the current branch via push
 + Refuse updating the current branch in a non-bare repository via
   push

----------------------------------------------------------------
[In 'pu']

* jn/gitweb-blame (Thu Aug 6 19:11:52 2009 +0200) 14 commits
 - gitweb: Create links leading to 'blame_incremental' using
   JavaScript
 - gitweb: Incremental blame (proof of concept)
 - gitweb: Add optional "time to generate page" info in footer
 + Revert the four topmost commits from jn/gitweb-blame topic
 + gitweb: Create links leading to 'blame_incremental' using
   JavaScript
 + gitweb: Incremental blame (proof of concept)
 + gitweb: Add optional "time to generate page" info in footer
 + gitweb: Add -partial_query option to href() subroutine
 + gitweb: Use light/dark for class names also in 'blame' view
 + gitweb: Add author initials in 'blame' view, a la "git gui blame"
 + gitweb: Mark commits with no "previous" in 'blame' view
 + gitweb: Use "previous" header of git-blame -p in 'blame' view
 + gitweb: Mark boundary commits in 'blame' view
 + gitweb: Make .error style generic

I haven't picked up Jakub's replacement to the second one from the tip.
We probably should merge up to "Use light/dark" (aef3768) to 'master' and
start the rest over.

* jc/maint-clean-nested-dir-safety (Tue Jun 30 15:33:45 2009 -0700) 1 commit
 + clean: require double -f options to nuke nested git repository and
   work tree

This probably should go in 'master' soonish.

* jc/shortstatus (Tue Aug 4 23:55:22 2009 -0700) 12 commits
 - git stat -s: short status output
 - git stat: pathspec limits, unlike traditional "git status"
 - git stat: the beginning
 + wt-status: collect untracked files in a separate "collect" phase
 + Make git_status_config() file scope static to builtin-commit.c
 + wt-status: move wt_status_colors[] into wt_status structure
 + wt-status: move many global settings to wt_status structure
 + commit: --dry-run
 + status: show worktree status of conflicted paths separately
 + wt-status.c: rework the way changes to the index and work tree are
   summarized
 + diff-index: keep the original index intact
 + diff-index: report unmerged new entries

Slowly progressing.  I've addressed issues pointed out by Jeff in his
review, and hopefully the whole thing would be ready to go.

* db/vcs-helper (Sun Aug 9 15:28:28 2009 -0400) 17 commits
 - Allow helpers to request marks for fast-import
 - Allow helpers to report in "list" command that the ref is
   unchanged
 - Add support for "import" helper command
 - transport-helper_init(): fix a memory leak in error path
 - Add a config option for remotes to specify a foreign vcs
 - Allow programs to not depend on remotes having urls
 - Allow fetch to modify refs
 - Use a function to determine whether a remote is valid
 - Use a clearer style to issue commands to remote helpers
 + Makefile: install hardlinks for git-remote-<scheme> supported by
   libcurl if possible
 + Makefile: do not link three copies of git-remote-* programs
 + Makefile: git-http-fetch does not need expat
 + http-fetch: Fix Makefile dependancies
 + Add transport native helper executables to .gitignore
 + git-http-fetch: not a builtin
 + Use an external program to implement fetching with curl
 + Add support for external programs for handling native fetches

This consolidates various previous rounds from Daniel and Johan.  It seems
that the use of colon ':' before vcs helper name needs to be corrected
before this series can go further.

* je/send-email-no-subject (Wed Aug 5 18:49:54 2009 +0200) 1 commit
 - send-email: confirm on empty mail subjects

This seems to break t9001.  Near the tip of 'pu' I have a iffy workaround.

* jh/notes (Wed Jul 29 04:25:26 2009 +0200) 8 commits
 - t3302-notes-index-expensive: Speed up create_repo()
 - fast-import: Add support for importing commit notes
 - First draft of notes tree parser with support for fanout subtrees
 - Teach "-m <msg>" and "-F <file>" to "git notes edit"
 - Add an expensive test for git-notes
 - Speed up git notes lookup
 - Add a script to edit/inspect notes
 - Introduce commit notes

* cc/sequencer-rebase-i (Wed Aug 5 22:53:00 2009 +0200) 8 commits
 - rebase -i: use "git sequencer--helper --reset-hard"
 - sequencer: add "--reset-hard" option to "git sequencer--helper"
 - sequencer: add comments about reset_almost_hard()
 - sequencer: add "reset_almost_hard()" and related functions
 - rebase -i: use "git sequencer--helper --make-patch"
 - sequencer: free memory used in "make_patch" function
 - sequencer: add "make_patch" function to save a patch
 - sequencer: add "builtin-sequencer--helper.c"

More sequencer updates.  I didn't look at the latest round that had a
handful "oops, fix that earlier botch" patches, expecting a cleaner
reroll.

* jc/mailinfo-remove-brackets (Wed Jul 15 15:31:12 2009 -0700) 1 commit
 - mailinfo: -b option keeps [bracketed] strings that is not a
   [PATCH] marker

* tr/reset-checkout-patch (Tue Jul 28 23:20:12 2009 +0200) 8 commits
 - DWIM 'git stash save -p' for 'git stash -p'
 - Merge branch 'js/stash-dwim' into tr/reset-checkout-patch
 - Make 'git stash -k' a short form for 'git stash save --keep-index'
 - Implement 'git stash save --patch'
 - Implement 'git checkout --patch'
 - Implement 'git reset --patch'
 - builtin-add: refactor the meat of interactive_add()
 - git-apply--interactive: Refactor patch mode code

Progress?

* js/stash-dwim (Mon Jul 27 20:37:10 2009 +0200) 1 commit
 - Make 'git stash -k' a short form for 'git stash save --keep-index'

This should be merged to 'next' soonish, but I keep forgetting.

* pb/tracking (Thu Jul 16 16:26:15 2009 -0500) 7 commits
 . branch.c: if remote is not config'd for branch, don't try delete
   push config
 . branch, checkout: introduce autosetuppush
 . move deletion of merge configuration to branch.c
 . remote: add per-remote autosetupmerge and autosetuprebase
   configuration
 . introduce a struct tracking_config
 . branch: install_branch_config and struct tracking refactoring
 . config: allow false and true values for branch.autosetuprebase

Has been ejected from 'pu' for some time, expecting a reroll.

* jc/log-tz (Tue Mar 3 00:45:37 2009 -0800) 1 commit
 - Allow --date=local --date=other-format to work as expected

Re: What's cooking in git.git (Aug 2009, #02; Wed, 12)

[Jakub Narebski]

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

> * mr/gitweb-xz (Thu Aug 6 10:28:25 2009 -0400) 3 commits
>  - gitweb: add support for XZ compressed snapshots
>  - gitweb: update INSTALL regarding specific snapshot settings
>  - gitweb: support to globally disable a snapshot format
> 
> This should be safe as long as it does not silently enable itself for
> folks who merely updated gitweb to this version without explicitly asking
> for the new format (but I do not remember if that is what the patch does).

The latest version (v5, from 6.08) has XZ compressed snapshot ('txz')
disabled by default.
 
> * zf/maint-gitweb-acname (Sun Aug 2 09:42:24 2009 +0200) 1 commit
>  - gitweb: parse_commit_text encoding fix

Good.

> * jn/gitweb-blame (Thu Aug 6 19:11:52 2009 +0200) 14 commits
>  - gitweb: Create links leading to 'blame_incremental' using
>    JavaScript
>  - gitweb: Incremental blame (proof of concept)
>  - gitweb: Add optional "time to generate page" info in footer
>  + Revert the four topmost commits from jn/gitweb-blame topic
>  + gitweb: Create links leading to 'blame_incremental' using
>    JavaScript
>  + gitweb: Incremental blame (proof of concept)
>  + gitweb: Add optional "time to generate page" info in footer
>  + gitweb: Add -partial_query option to href() subroutine
>  + gitweb: Use light/dark for class names also in 'blame' view
>  + gitweb: Add author initials in 'blame' view, a la "git gui blame"
>  + gitweb: Mark commits with no "previous" in 'blame' view
>  + gitweb: Use "previous" header of git-blame -p in 'blame' view
>  + gitweb: Mark boundary commits in 'blame' view
>  + gitweb: Make .error style generic
> 
> I haven't picked up Jakub's replacement to the second one from the tip.
> We probably should merge up to "Use light/dark" (aef3768) to 'master' and
> start the rest over.

That would be good idea.
 
[...]

What about 'gitweb: fix variable scoping issue in git_get_projects_list'
latest version of patch, adding (re)declaring $project_maxdepth,
$projectroot as global variables using our?  Or are you waiting for
response of our resident Perl expert: Randal L. Schwartz (merlyn)?

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: What's cooking in git.git (Aug 2009, #02; Wed, 12)

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

>> * jn/gitweb-blame (Thu Aug 6 19:11:52 2009 +0200) 14 commits
>>  - gitweb: Create links leading to 'blame_incremental' using
>>    JavaScript
>>  - gitweb: Incremental blame (proof of concept)
>>  - gitweb: Add optional "time to generate page" info in footer
>>  + Revert the four topmost commits from jn/gitweb-blame topic
>>  + gitweb: Create links leading to 'blame_incremental' using
>>    JavaScript
>>  + gitweb: Incremental blame (proof of concept)
>>  + gitweb: Add optional "time to generate page" info in footer
>>  + gitweb: Add -partial_query option to href() subroutine
>>  + gitweb: Use light/dark for class names also in 'blame' view
>>  + gitweb: Add author initials in 'blame' view, a la "git gui blame"
>>  + gitweb: Mark commits with no "previous" in 'blame' view
>>  + gitweb: Use "previous" header of git-blame -p in 'blame' view
>>  + gitweb: Mark boundary commits in 'blame' view
>>  + gitweb: Make .error style generic
>> 
>> I haven't picked up Jakub's replacement to the second one from the tip.
>> We probably should merge up to "Use light/dark" (aef3768) to 'master' and
>> start the rest over.
>
> That would be good idea.

Thanks, will do.

> What about 'gitweb: fix variable scoping issue in git_get_projects_list'
> latest version of patch, adding (re)declaring $project_maxdepth,
> $projectroot as global variables using our?  Or are you waiting for
> response of our resident Perl expert: Randal L. Schwartz (merlyn)?

Not in my queue, but no need to resend --- I can find it.

jc/shortstatus (was: What's cooking in git.git (Aug 2009, #02; Wed, 12))

[Jeff King]

On Wed, Aug 12, 2009 at 07:14:53PM -0700, Junio C Hamano wrote:

> * jc/shortstatus (Tue Aug 4 23:55:22 2009 -0700) 12 commits
>  - git stat -s: short status output
>  - git stat: pathspec limits, unlike traditional "git status"
>  - git stat: the beginning
>  + wt-status: collect untracked files in a separate "collect" phase
>  + Make git_status_config() file scope static to builtin-commit.c
>  + wt-status: move wt_status_colors[] into wt_status structure
>  + wt-status: move many global settings to wt_status structure
>  + commit: --dry-run
>  + status: show worktree status of conflicted paths separately
>  + wt-status.c: rework the way changes to the index and work tree are
>    summarized
>  + diff-index: keep the original index intact
>  + diff-index: report unmerged new entries
> 
> Slowly progressing.  I've addressed issues pointed out by Jeff in his
> review, and hopefully the whole thing would be ready to go.

I briefly looked over what's in next, and the fixes you made look good
to me. I've been running with this series for a little while, and I was
very pleased when "git status" showed me a more detailed description of
some unmerged paths the other day. :)

For the "git stat" portion still in pu, I have a few comments/questions:

  1. Is "stat" a good name? I worry a little that it is _too_ similar to
     "status", and that will cause confusion while they both exist. So
     something like "git overview" would cause less confusion, and even
     though it sucks to type, it will eventually replace "status" (and
     in the meantime people can make aliases or whatever).

  2. Does it really belong in builtin-commit.c anymore? It seems like
     historical accident that "status" is so closely tied to commit. The
     whole point of the new command is to _not_ be tied; I think of the
     new command more as an extension of 'diff'. Admittedly, users don't
     care where the source is located, but it helps the developers
     understand the relationships between code.

  3. Can you squash in the gitignore patch below? :)

---
diff --git a/.gitignore b/.gitignore
index c446290..14e0f51 100644
--- a/.gitignore
+++ b/.gitignore
@@ -128,6 +128,7 @@ git-show-index
 git-show-ref
 git-stage
 git-stash
+git-stat
 git-status
 git-stripspace
 git-submodule

Re: jc/shortstatus

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> For the "git stat" portion still in pu, I have a few comments/questions:
>
>   1. Is "stat" a good name? I worry a little that it is _too_ similar to
>      "status", and that will cause confusion while they both exist. So
>      something like "git overview" would cause less confusion, and even
>      though it sucks to type, it will eventually replace "status" (and
>      in the meantime people can make aliases or whatever).

It is handy to have both available while asking others help debugging the
version in 'pu', and that is the only reason for the separate command.  It
could have been named 'git frotz' for all I care ;-)

I do not intend to make it another "git merge-recur"; I would actually
want to have it replace "status" before the series goes to 'next'.

I hopefully will have some time to start doing that over the weekend; the
first step would be to rename the branch to jc/1.7.0-status and get rid of
cmd_status() from builtin-commit.c.

A few points I haven't managed to think about, decide, nor test, are:

 - What should its exit code be?  Should it be consistent with the
   traditional "git status" at least when no paths are given, signallying
   failure when nothing is staged for committing, so that ancient out of
   tree scripts people may have written would not break too badly when we
   make the switch?

 - What should its default mode of output be?  Do people prefer "svn st"
   style short-format output, or should we stay verbose and explanatory?

 - Is it handling corner cases correctly?  e.g. Does it operate correctly
   when run from a subdirectory?  How should it handle submodules?  Before
   the initial commit?  Use of colors?

>   2. Does it really belong in builtin-commit.c anymore? It seems like
>      historical accident that "status" is so closely tied to commit. The
>      whole point of the new command is to _not_ be tied; I think of the
>      new command more as an extension of 'diff'. Admittedly, users don't
>      care where the source is located, but it helps the developers
>      understand the relationships between code.

It would make sense to create a separate builtin-status.c.  I haven't
looked at the dependencies yet, but it shouldn't be too bad.  We'll see.

>   3. Can you squash in the gitignore patch below? :)

Yes but hopefully it won't be necessary ;-)

Re: jc/shortstatus

[Jeff King]

On Sat, Aug 15, 2009 at 01:18:28AM -0700, Junio C Hamano wrote:

> It is handy to have both available while asking others help debugging the
> version in 'pu', and that is the only reason for the separate command.  It
> could have been named 'git frotz' for all I care ;-)
> 
> I do not intend to make it another "git merge-recur"; I would actually
> want to have it replace "status" before the series goes to 'next'.

Ah, OK. I thought we were going to live through 1.6.5 with the dual
commands. But if it is going to be "status", I don't care at all what it
is called in the interim. :)

>  - What should its exit code be?  Should it be consistent with the
>    traditional "git status" at least when no paths are given, signallying
>    failure when nothing is staged for committing, so that ancient out of
>    tree scripts people may have written would not break too badly when we
>    make the switch?

If I were designing it from scratch, I would say the exit code should be
the opposite. That is, it is really about doing several diffs, and if
there are no changes, then we should, like diff, exit zero.

If you want to know whether there is something to commit, you wouldn't
to use this tool. If you just want to know if there is something in the
index to commit, you would use diff-index. If you want to see if
some set of commit parameters would make a commit, you would use "commit
--dry-run".

So really there is only the historical argument. I am inclined not to
worry about it. We are already breaking compatibility in other ways
(like how command line parameters are treated), so you are really only
helping people whose scripts use a subset of the current "git status"
functionality. And since this is the time for breaking, I think it's
best to make all of the changes we want, and not have another
half-breakage later.

>  - What should its default mode of output be?  Do people prefer "svn st"
>    style short-format output, or should we stay verbose and explanatory?

Personally I prefer the long format, but maybe just because I'm used to
it. I suspect others want the short format. This really should be a
porcelain command[1], so I don't see a problem with a
status.outputformat config option.

[1] One can, after all, call diff-index, diff-files, and "ls-files -o"
to get the same information from plumbing. If we really want to provide
plumbing that pulls them all together (e.g., because it is more
efficient or more convenient to do it all in one command), then I think
we should provide "git status --porcelain".

>  - Is it handling corner cases correctly?  e.g. Does it operate correctly
>    when run from a subdirectory?  How should it handle submodules?  Before
>    the initial commit?  Use of colors?

I'll try out a few things, but I think largely we will need to put it in
"next" to shake out any bugs.

-Peff

Re: jc/shortstatus

[Junio C Hamano]

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

> A few points I haven't managed to think about, decide, nor test, are:
>
>  - What should its exit code be?  Should it be consistent with the
>    traditional "git status" at least when no paths are given, signallying
>    failure when nothing is staged for committing, so that ancient out of
>    tree scripts people may have written would not break too badly when we
>    make the switch?
>
>  - What should its default mode of output be?  Do people prefer "svn st"
>    style short-format output, or should we stay verbose and explanatory?
>
>  - Is it handling corner cases correctly?  e.g. Does it operate correctly
>    when run from a subdirectory?  How should it handle submodules?  Before
>    the initial commit?  Use of colors?

Just a quick status update, lest others waste too much time staring at the
series I posted last night.

 - Leading and trailing comments (e.g. "On branch foo", "Initial commit",
   "# No changes", ...) were missing.
 - Did not honor -v to show "diff --cached".
 - Subdirectory behaviour (status.relativepath configuration) was broken.

I have a version that fixes the above, and exits 0 when there is no error
(i.e. does not exit non-zero on clean index).  There are existing tests
that expect "git status" erroring out on clean index and there are some
that depends on "git status paths..." to show preview of a partial commit,
which needed to be replaced with "git commit --dry-run", but as far as I
can tell, I've took care of them all.

I am still feeling uneasy about the exit status change (the test scripts
are sources of how people who script around git take their inspirations
after all), but I'll send the result out for a review later without
changing that back to "exit failure when there is nothing to commit".