Re: What's cooking in git.git (Feb 2009, #05; Mon, 16)

[Jakub Narebski <jnareb@gmail.com>]

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

> ----------------------------------------------------------------
> [New Topics]
> 
> * gb/gitweb-base (Sun Feb 15 10:18:36 2009 +0100) 1 commit
>  - gitweb: fix wrong base URL when non-root DirectoryIndex
> 
> Should this go in 1.6.2-rc2?

Isn't it in master already?

> 
> * tr/gcov (Sun Feb 15 23:25:45 2009 +0100) 8 commits
>  - Test git-patch-id
>  - Test rev-list --parents/--children
>  - Test log --decorate
>  - Test fsck a bit harder
>  - Test log --graph
>  - Test diff --dirstat functionality
>  - Test that diff can read from stdin
>  - Support coverage testing with GCC/gcov

Hmmmm... wouldn't it be nice to have more tests?

> 
> * jc/add-p-unquote (Mon Feb 16 22:43:43 2009 -0800) 1 commit
>  - git-add -i/-p: learn to unwrap C-quoted paths

It might be considered bugfix, but IIRC it is still cooking,
so perhaps it wouldn't be absolutely ready for 1.6.2

> 
> ----------------------------------------------------------------
> [Stalled and may need help and prodding to go forward]
> 
> * jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
>  + blame: show "previous" information in --porcelain/--incremental
>    format
>  + git-blame: refactor code to emit "porcelain format" output
> 
> This gives Porcelains (like gitweb) the information on the commit _before_
> the one that the final blame is laid on, which should save them one
> rev-parse to dig further.  The line number in the "previous" information
> may need refining, and sanity checking code for reference counting may
> need to be resurrected before this can move forward.
> 
> I thought recent tig discussion may blow new life into it, but is this
> unneeded?  If so I'd rather revert it (or discard after 1.6.2).

It would be nice to have for gitweb... especially if it is a merge
commit that gets the blame (which I guess should happen only for 'evil
merge' case).

> 
> * db/foreign-scm (Sun Jan 11 15:12:10 2009 -0500) 3 commits
>  - Support fetching from foreign VCSes
>  - Add specification of git-vcs helpers
>  - Add "vcs" config option in remotes
> 
> The "spec" did not seem quite well cooked yet, but in the longer term I
> think something like this to allow interoperating with other SCMs as if
> the other end is a native git repository is a very worthy goal.

I wonder what are the limitations: I guess that importer has to be
incremental (and probably store additional info, or at least cache
it).  IIRC the example was for Perforce; much more interesting would
be to have example for Subversion, I guess.

> 
> * cc/replace (Mon Feb 2 06:13:06 2009 +0100) 11 commits
>  - 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
> 
> I think the code is much cleaner than the first round, but I am not
> convinced it is doing the right thing in the connectivity traverser.  
> Independent review sorely needed.

This is certainly something that it would be nice to have.

> 
> * sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits
>  - gitweb: Optional grouping of projects by category
>  - gitweb: Split git_project_list_body in two functions
>  - gitweb: Modularized git_get_project_description to be more generic
> 
> Design discussion between Jakub and Sebastien seems to have stalled, but
> Jakub seems to be taking this over.

The fact that discussion stalled is largely my fault as reviewer
wanting for this series to do too much 'by the way' changes, and
preparation for further changes.

I don't know when I would have time to actively work on this, but I
have it in my repository, so it wouldn't vanish

  git://repo.or.cz/git/jnareb-git.git gitweb/category
  http://repo.or.cz/w/git/jnareb-git.git?a=shortlog;h=refs/heads/gitweb/category

> 
> * jc/fsck (Fri Jan 30 02:33:47 2009 -0800) 4 commits
>  - fsck: three levels of validation
>  - verify-pack: add --quick
>  - verify_pack(): allow a quicker verification for a pack with
>    version 2 idx
>  - pack-check.c: minor formatting fix to match coding style
> 
> J6t has a good point that if this had any value then medium level should
> replace the default.  I am tempted to actually dropping this as a failed
> experiment.

I recall that medium level wasn't that much faster, isn't it?

-- 
Jakub Narebski
Poland
ShadeHawk on #git