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/
directory? - 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. Volunteers?
- 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. Volunteers?
- 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
it.
- 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
it.
- 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
them.
- 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.
Horst von Brand
