Re: What to expect after 0.99.8

From: A Large Angry SCM <gitzilla@gmail.com>
Date: Oct 3, 2005, 03:06 UTC
Message-ID: <4340A01F.7040901@gmail.com>
In-Reply-To: <7v7jcvxxrl.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano wrote:

Show 15 quoted lines

> As I mentioned in teh 0.99.8 announcement, let's start aiming
> for 1.0, really this time.  From now on, brown paper bags,
> bugfixes, portability fixes, usability enhancements including
> documentation updates take precedence over any new features.
> One exception area is probably merge strategy modules -- they
> are like adding new device drivers or adding new filesystem, and
> can come in anytime as long as they do not touch the coreish.
> 
> 
> The GIT To-Do File
> ==================
> 
>   The latest copy of this document is found at 
> 
>     http://kernel.org/git/?p=git/git.git;a=blob;hb=todo;f=TODO

If you were to publish the ToDo to the mailing list once a week it might encourage more of those patches you want to accept.

...

> 
> * Maybe update tutorial with a toy project that involves two or
>   three developers..

This is *important* to have for 1.0.

> 
> * Update tutorial to cover setting up repository hooks to do
>   common tasks.

This is nice to have for 1.0.

> 
> * Accept patches to finish missing docs.

A list of missing, incomplete, and/or wrong docs in the ToDo file would help focus effort when people (like me) have space cycles.

> 
> * Accept patches to talk about "Whoops, it broke.  What's
>   next?".

This is *important* to have for 1.0.

> 
> * Accept patches to make formatted tables in asciidoc to work
>   well in both html and man pages (see git-diff(1)).

A Git documentation asciidoc style guide and howto would be _very_ useful. The current Git documentation is not all that consistent. (and I accept the blame for the docs I wrote)

> 
> 
> Technical (heavier)
> -------------------

...

> 
> * Maybe a pack optimizer.

Huh?

...

Show 6 quoted lines

> 
> * Internally split the project into non-doc and doc parts; add
>   an extra root for the doc part and merge from it; move the
>   internal doc source to a separate repository, like the +Meta
>   repository; experiment if this results in a reasonable
>   workflow, and document it in howto form if it does.

I think this is a bad idea. The docs should be part of the project (repository and head) as the code. Otherwise, they'll become even more out-of-sync.

...

> 
> Technical (trivial)
> -------------------
>

...

> 
> * 'git merge-projects'?

Huh?

Show 5 quoted lines

> 
> * 'git lost-and-found'?  Link dangling commits found by
>   fsck-objects under $GIT_DIR/refs/lost-found/.  Then
>   show-branch or gitk can be used to find any lost commit. [A
>   feeler patch sent out. Very underwhelming response X-<.]

The response may have been underwhelming but it's still a good idea.

> 
>   Do not name it /lost+found/; that would probably confuse
>   things that mistake it a mount point (not our code but
>   somebody else's).

I the this concern is overblown.

...