git/TODO

156 lines
5.0 KiB
Plaintext
Raw Blame History

This file contains invisible Unicode characters!

This file contains invisible Unicode characters that may be processed differently from what appears below. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to reveal hidden characters.

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
What to expect until and after 1.0
==================================
This is written in a form of to-do list for me, so if I say
"accept patch", it means I do not currently plan to do that
myself. People interested in seeing it materialize please take
a hint. Also whatever I marked "Perhaps" do not have to happen
if ever -- only if somebody cares enough and submits a clean
patch, perhaps ;-).
Only handful things remain until 1.0.
Documentation
-------------
* Accept patches from people who actually have done CVS
migration and update the cvs-migration documentation.
Link the documentation from the main git.txt page.
* Talk about using rsync just once at the beginning when
initializing a remote repository so that local packs do not
need to be expanded. I personally do not think we need tool
support for this (but see below about optimized cloning).
* Maybe update tutorial with a toy project that involves two or
three developers.
* Update tutorial to cover setting up repository hooks to do
common tasks [Mostly done, with Carl's help].
* Do we still have missing docs? If so accept patches to finish
them.
* Accept patches to talk about "Whoops, it broke. What's
next?" [I think this is done].
* Accept patches to make formatted tables in asciidoc to work
well in both html and man pages (see git-diff(1)) [DONE --
avoid them ;-)].
* Work around multiple synopses lines in manual pages
(e.g. git-bisect) [DONE -- avoid them ;-)].
Technical (heavier)
-------------------
* Libification. There are many places "run once" mentality is
ingrained in the management of basic data structures, which
need to be fixed. [Matthias Urlichs is already working on
this: <pan.2005.10.03.20.48.52.132570@smurf.noris.de>; Post
1.0].
* Maybe a pack optimizer.
Given a set of objects and a set of refs (probably a handful
branch heads and point release tags), find a set of packs to
allow reasonably minimum download for all of these classes of
people: (1) somebody cloning the repository from scratch, (2)
somebody who tends to follow the master branch head reasonably
closely, (3) somebody who tends to follow only the point
releases.
This needs a matching smart on the dumb protocol downloader.
[Definitely post 1.0].
* Maybe an Emacs VC backend.
* Look at libified GNU diff CVS seems to use, or libxdiff.
[Daniel has his own diff tool almost ready to start
integrating and testing; Post 1.0]
* Plug-in file-level merges [Post 1.0]. On the other hand, we
may not even need this; just tell people to run "xxdiff -U" on
the working tree files.
* Ref namespace management. Perhaps use refs/local/ suggestion
by Linus. [Does not seem to be high on people's priority list,
and not interested myself. People can resurrect this
discussion if they want.]
Technical (milder)
------------------
* strip leading directory from ls-tree output, to match ls-files
output.
I am of two minds about this one. diff output must always be
-p1 format no matter where the command was started, and
ls-tree might be easier to use if it matched diff, not
ls-files.
* diff stopping at the first output; qgit wants to know if this
tree has any A or D from the other tree and nothing else.
Would help internal tree-diff in rev-list as well [can be post
1.0].
* merge-recursive needs to register conflicting paths as higher
stage entries in the index. For that, it first needs to
construct three trees whose paths are already renamed, and
call 3-way read-tree. Alternatively, update-index needs to
give it a way to construct higher stages [DONE using the
"alternatively" implementation].
* daemon --strict-symlink [can be post 1.0].
* Binary package split. Plan laid out and discussion mostly
done. [RPM side done; Debian side thrown over the wall.]
* Perhaps detect cloning request in upload-pack and cache the
result for next cloning request until any of our refs change.
* Perhaps accept patch to optionally allow '--fuzz' in
'git-apply'.
* Allow 'git apply' to accept GNU diff 2.7 output that forgets
to say '\No newline' if both input ends with incomplete
lines.
* Maybe grok PGP signed text/plain in applymbox as well.
* Enhance "git repack" to not always use --all; this would be
handy if the repository contains wagging heads like "pu" in
git.git repository.
* Output full path in the "git-rev-list --objects" output, not
just the basename, and see the improved clustering results in
better packing [Tried, but did not work out well].
Technical (trivial)
-------------------
* We would want test scripts for the relative directory path
stuff Linus has been working on. Most of the C-level
commands should be usable with relative directory paths.
* In a freashly created empty repository, `git fetch foo:bar`
works OK, but `git checkout bar` afterwards does not (missing
`.git/HEAD`).
Local Variables:
mode: text
End: