Daniel Barkalow <[EMAIL PROTECTED]> writes:

> It might be worth putting the list of things left to do before 1.0 in the 
> tree (since they clearly covary), and it would be useful to know what 
> you're thinking of as preventing the release at any particular stage.

Yeah, yeah.  Call me lazy.

Excerpts from my "last mile to 1.0", my Itchlist, and pieces from
random other messages since then.

- Documentation. [I really need help here --- among ~7000 lines
  there, I've written around 2500 lines, David Greaves another
  2500, and Linus 1400.  And it is not very easy to proofread
  what you wrote yourself.]

  - Are all the core commands described in Documentation/

  - Many files under Documentation/ directory have become stale.
    I've tried to do one pass of full sweep recently [and
    another since I wrote the original "last mile" message], but
    I'd like somebody else to make another pass to make sure
    that the usage strings in programs, what the programs do,
    and what Documentation says they do match.  Also, the
    spelling and grammar fixes, which I am very bad at and have
    not done any attempt, needs to be done.


  - Are all the files in Documentation/ reachable from git(7)
    or otherwise made into a standalone document using asciidoc
    by the Makefile?  I haven't looked into documentation
    generation myself (I use only the text files as they are);
    help to update the Makefile by somebody handy with asciidoc
    suite is greatly appreciated here.


  - We may want to describe more Best Current Practices, along
    the lines of "Working with Others" section in the tutorial.
    Please write on your faviorite topic and send patches in
    ;-)) [ryan started collecting Documentation/howto which
    would greatly help in this area].

  - Glossary documentation Johannes Schindelin is working on.

    I think coming up with the concensus of terms would come
    fairly quickly on the list.  Updating docs to match the
    concensus may take some time.  Help is greatly appreciated.

  - Maybe doing another pass at tutorial.  Could somebody run
    (or preferably, find a friend who has never touched git and
    have her run) the tutorial examples from the beginning to
    the end, and find rooms of improvements?  Does the order of
    materials presented make sense?  Do we talk about things
    assuming that the user knows something else that we have not
    talked about?  Have we introduced better way of doing the
    same thing since the tutorial was written?

    I've done that once with the text that is currently in the
    head of the master branch, but that is getting rather stale,
    and also I did that myself so I am sure I've sidestepped
    pitfalls without even realizing.

The above does not have to be all there in 0.99.5, but I
consider that lack of any of the above to block 1.0.

- Commit walker downloading from packed repository is finally
  complete.  Thanks, Daniel!

- Teach fetch-pack reference renaming.

  On the push side, send-pack now knows updating arbitrary
  remote references from local references.  We need something
  similar for fetching [since then I outlined the design of the
  new shorthand file format and semantics but have not got
  around to actually do it.  Maybe on my next GIT day...].  This
  is scheduled for 0.99.5.

- commit template filler discussed with Pasky some time ago,
  with perhaps pre-commit and post-commit hooks.  Somehow the
  discussion died out but that does not mean _I_ forgot about

- Binary packaging.  Should _I_ worry about "/usr/bin/git" stay
  there myself --- I think not.  But I _do_ want to help Debian
  packaging folks if that path is causing problems in their
  effort to push git-core into the official Debian archive.

  As Linus mentioned earlier, this seems to be a Debian specific
  problem, and will not block 1.0 --- if Debian heavyweights do
  not want to stay compatible with the rest of the world, so be

- I have not heard from Darwin or BSD people for some time.  Is
  your portfile up to date?  Do you have updates you want me to
  include?  Have we introduced non-Linux non-GNU
  incompatibilities lately that you want to see fixed and/or
  worked around?

  Again, I consider binary packaging issue independent from our
  release schedule; it is a distribution local issue, so this
  would not block 1.0 in any way.  But I _am_ willing to help

- Oh, another itch I did not list in the previous message.  Is
  anybody interested in doing an Emacs VC back-end for GIT?

- git prune and git fsck-cache; think about their interactions
  with an object database that borrows from another.  This
  includes the case where .git/objects itself is symlinked to
  somewhere else (i.e. running "git prune" that somewhere else
  without consulting this repository would lose objects), and
  alternates pointing at somewhere else (i.e. ditto).

  My personal feeling is that we should just warn users about
  doing .git/objects symlinking and/or alternates pointing ---
  do not do it unless you have an off-line arrangement with the
  owner of the repository you are borrowing from.  Even if that
  would become our official position to take, it needs to be
  documented clearly before we declare this issue to have been
  "dealt with".

I am sure I am forgetting something, but the above would be a
good start.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to