Re: What to expect after 0.99.8

Junio C Hamano wrote:

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?

...

* 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?

* '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.

...