Re: What's cooking in git.git (topics)

[Jakub Narebski <jnareb@gmail.com>]

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

> * jk/noetcconfig (Wed Feb 6 05:11:53 2008 -0500) 2 commits
>  + fix config reading in tests
>  + allow suppressing of global and system config
> 
> * lh/gitdir (Mon Feb 4 21:59:21 2008 +0100) 4 commits
>  - git-submodule: prepare for the .git-file
>  - Add tests for .git file
>  - Document the .git-file
>  - Add platform-independent .git "symlink"
> 
> Seems to have funny interaction with Jeff King's test script
> updates.

I think that gitdir is a very good idea, but needs further testing.
 
> * ph/describe-match (Mon Dec 24 12:18:22 2007 +0100) 2 commits
>  + git-name-rev: add a --(no-)undefined option.
>  + git-describe: Add a --match option to limit considered tags.

This looks nice. I'd like also to have some kind of --pretty=<format>
(or --format=<format>) for git-describe, and a way to limit both
git-name-rev and git-describe to only *signed* commits.

With this it would be fairly easy in generating git.spec file
from git.spec.in to check if we are on tagged release and use
pre-compiled manpages if it is the case. Although perhaps option
(default?) to use pre-compiled manpages (even if they are outdated
a bit) instead of requiring asciidoc toolchain would be better;
this would make SRPM size larger, as it would contain manpages.
 

> * nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
>  - Move all dashed-form commands to libexecdir
> 
> Scheduled for 1.6.0.  I am not sure if we should merge this to
> 'next' before 1.5.5.  Most active people will be on 'next' and
> if we have this there, the resulting 1.5.5 release might end up
> having issues that come from differences this one introduces.

Perhaps we should first generate libexecdir separate from bindir,
and put helper scripts there (the *--* scripts), to not pollute
PATH with commands which are never meant to be called directly
by user.
 
> * bf/remote-head (Sun Dec 23 20:52:32 2007 -0500) 1 commit
>  . git-remote: make add -f guess HEAD, as clone does
> 
> I might have carefully looked at this in the past but I do not
> recall if there were issues.  Need re-reviewing and help from
> the list is appreciated.

I'd rather below get implemented, so there isn't any guessing
involved.
 
> * jc/git-symref (Tue Dec 11 16:42:46 2007 -0800) 1 commit
>  . PARK: show-symref protocol extension.

What are the plans on git-clone builtinification (and cleaning up
clone progress and error messages[*1*])?

[*1*] http://texagon.blogspot.com/2008/02/let-play-git.html
-- 
Jakub Narebski
Poland
ShadeHawk on #git