Re: What's cooking in git.git (Feb 2009, #03; Sat, 07)

[Jakub Narebski <jnareb@gmail.com>]

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

> ----------------------------------------------------------------
> [New Topics]
> 
> * jn/gitweb-committag (Fri Feb 6 10:12:41 2009 +0100) 1 commit
>  + gitweb: Better regexp for SHA-1 committag match

The v1, with adding word boundary only, isn't it?
 
> ----------------------------------------------------------------
> [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.
> 
> Recent tig discussion may blow new life into it.  Let's see.

I think that in gitweb we can simply relax admissible (valid) values
for 'h'/'hb'/'hbp' parameters (currently checked by validate_refname)
and allow combination of ^, ^<n>, and ~<n> suffixes, and simply resolve
them only if user click on the link (perhaps using redirect like for
generic 'object' view).

The "previous" information doesn't solve the problem what was
the line number of line before change... but it might help tig.
 
> * 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.

I tried to redo the patches, but 2nd do not apply using "git am -3"
because of changes in gitweb.  Sebastien, could you resend this series,
marking it as [PATCHv3 n/3 (resend)] or something like that (unless you
would modify them)?
 
> ----------------------------------------------------------------
> [Actively cooking]
>
> * js/valgrind (Thu Feb 5 22:03:00 2009 +0100) 9 commits
>  + valgrind: do not require valgrind 3.4.0 or newer
>  + test-lib: avoid assuming that templates/ are in the GIT_EXEC_PATH
>  + Tests: let --valgrind imply --verbose and --tee
>  + Add a script to coalesce the valgrind outputs
>  + t/Makefile: provide a 'valgrind' target
>  + test-lib.sh: optionally output to test-results/$TEST.out, too
>  + Valgrind support: check for more than just programming errors
>  + valgrind: ignore ldso and more libz errors
>  + Add valgrind support in test scripts

This would help finding bugs in feature freeze, wouldn't it?

> ----------------------------------------------------------------
> [Graduated to "master"]
> 
> * js/notes (Tue Jan 13 20:57:16 2009 +0100) 6 commits
>  + git-notes: fix printing of multi-line notes
>  + notes: fix core.notesRef documentation
>  + Add an expensive test for git-notes
>  + Speed up git notes lookup
>  + Add a script to edit/inspect notes
>  + Introduce commit notes

Nice!

-- 
Jakub Narebski
Poland
ShadeHawk on #git