2005-12-05 midnight
[git.git] / TODO
diff --git a/TODO b/TODO
index f650d28..d97fc7a 100644 (file)
--- a/TODO
+++ b/TODO
@@ -6,38 +6,17 @@ The GIT To-Do File
     http://kernel.org/git/?p=git/git.git;a=blob;hb=todo;f=TODO
 
 
-Tool Renames Plan
-=================
-
- - In 0.99.7, all renamed commands have symbolic links in
-   $(bindir) so that old names continue to work.  These backward
-   compatible names will not appear in documentation.  The main
-   documentation, git(7) will talk about the new names but would
-   mention their old names as historical notes.  Old environment
-   names defined in gitenv() will also be removed in this release.
-
- - In 0.99.8, we will not install these backward compatible
-   symbolic links in $(bindir) anymore.  The Makefile will have
-   a target to remove old symlinks from $(DESTDIR)$(bindir) you
-   can run manually to help you clean things up.
-
-   As a notable exception, git-ssh-push and git-ssh-pull pair is
-   not going away within this timeframe, if ever.  Each of these
-   old-name commands continues to invoke its old-name
-   counterpart on the other end.  Updating to 0.99.8 on one end
-   of the connection does not requier the other end to update at
-   the same time.
-
-   The timeframe for this is around Oct 1st.
-
-
-What to expect after 0.99.7
-===========================
+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.
+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
@@ -47,104 +26,98 @@ Documentation
   migration and update the cvs-migration documentation.
   Link the documentation from the main git.txt page.
 
-* Accept patches from people who were hit by shiny blue bat to
-  update the SubmittingPatches.
-
 * 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..
-
-* Document octopus [Linus prodded me again; DONE].
+  three developers.
 
 * Update tutorial to cover setting up repository hooks to do
   common tasks.
 
-* Accept patches to finish missing docs.
+* Do we still have missing docs?  If so accept patches to finish
+  them.
 
 * Accept patches to talk about "Whoops, it broke.  What's
-  next?".
+  next?" [ONGOING].
 
 * Accept patches to make formatted tables in asciidoc to work
   well in both html and man pages (see git-diff(1)).
 
+* Work around multiple synopses lines in manual pages
+  (e.g. git-bisect).
+
 
 Technical (heavier)
 -------------------
 
-* Tony Luck reported an unfortunate glitch in the 3-way merge.
-  Encourage discussions to come up with a not-so-expensive way
-  to catch the kind of ambiguities that led to his misery.
-  [Deathmatch between Daniel's and Fredrik's ongoing.]
-
-* HPA has two projects, klibc and klibc-kbuild, that have large
-  set of overlapping files in different paths (i.e. one has many
-  renames from the other).  There currently is no way for git to
-  help keep these two trees in sync, merging criss-cross between
-  them.  The merge logic should be able to take advantage of
-  rename/copy detection smarts git-diff-* family has.  Linus,
-  me, and Daniel outlined a smarter merge strategy for this.
-  Try them out.
-
-* We might want to optimize cloning with GIT native transport
-  not to explode the pack, and store it in objects/pack instead.
-  We would need a tool to generate an idx file out of a pack
-  file for this.  Also this itself may turn out to be a bad
-  idea, making the set of packs in repositories everybody has
-  different from each other.
-
 * Libification.  There are many places "run once" mentality is
   ingrained in the management of basic data structures, which
-  need to be fixed.
+  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.
 
-* 'git split-projects'?  This requires updated 'git-rev-list' to
-  skip irrelevant commits.
-  Message-ID: <Pine.LNX.4.63.0509221617300.23242@iabervon.org>
+* 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.
 
-* Look at libified GNU diff CVS seems to use.
+* 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)
 ------------------
 
-* Revisit 'git-merge'.  It probably was a mistake to "loop to
-  choose the best one", since what is best is not ill defined to
-  begin with.  This would make it a lot straightforward to
-  loosen the tree cleanliness requirements to the acceptable
-  level [DONE].
-
-* The recent commit walker safety patch may be too cautious and
-  appears to take forever when cloning.  This may even be
-  infinitely looping in the code lifted from the old rev-list --
-  needs to be taken a look at [DONE -- and redone very nicely by
-  Sergey].
+* strip leading directory from ls-tree output, to match ls-files
+  output.
 
-* Encourage concrete proposals to commit log message templates
-  we discussed some time ago.
+  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.
 
-* Accept patches for more portability.
+* 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].
 
-  * strcasestr() in mailinfo.  We may need compat/strcasestr.c;
-    this is bugging OpenBSD folks [DONE, thanks to Linus and
-    others].
+* 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 [can be post 1.0, but
+  nicer to have in 1.0].
 
-  * Solaris portability [ONGOING, thanks to Patrick Mauritz,
-    Peter Eriksen and Sean from sympatico].
+* daemon --strict-symlink [can be post 1.0].
 
-* Accept patches to cause "read-tree -u" delete a directory when
-  it makes it empty.
+* Binary package split.  Plan laid out and discussion mostly
+  done. [RPM side done; Debian side thrown over the wall.]
 
-* Perhaps accept patches to introduce the concept of "patch flow
-  expressed as ref mappings" Josef has been advocating about.
-
-* Perhaps accept patches to do undo/redo.
+* 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'.
@@ -155,77 +128,21 @@ Technical (milder)
 
 * Maybe grok PGP signed text/plain in applymbox as well.
 
-* Perhaps a tool to revert a single file to pre-modification
-  state?  People with BK background know this operation as
-  'clean'.  'git checkout [-f] ent [path...]' was suggested by
-  Matthias Urlichs which sounds a natural extention to what the
-  command currently does.
-
 * Enhance "git repack" to not always use --all; this would be
   handy if the repository contains wagging heads like "pu" in
   git.git repository.
 
-* 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.
-
-* Make rebase restartable; instead of skipping what cannot be
-  automatically forward ported, leave the conflicts in the work
-  tree, have the user resolve it, and then restart from where it
-  left off.
-
 * 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].
 
-* Remove obsolete commands [DONE].
-
-* Option to limit rename detection for more than N paths [READY].
-
-* Option to show only status and name from diff [READY].
-
-* What to name the 'master' version between 0.99.7 and 0.99.8
-  and still not break binary distribution folks?  0.99.7z?
-  Pasky gave me a good one: 0.99.7.GIT [DONE]
-
 
 Technical (trivial)
 -------------------
 
-* show-branch naming heads is buggy [FIXED].
-
-* Stop installing the old-name symlinks [DONE].
-
-* 'git add --recursive' [DONE]
-
-* 'git merge-projects'?
-
-* '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-<.]
-
-  Do not name it /lost+found/; that would probably confuse
-  things that mistake it a mount point (not our code but
-  somebody else's).
-
-* Add simple globbing rules to git-show-branch so that I can
-  say 'git show-branch --heads "ko-*"' (ko-master, ko-pu, and
-  ko-rc are in refs/tags/).
-
 * We would want test scripts for the relative directory path
-  stuff Linus has been working on.  So far, the following
-  commands should be usable with relative directory paths:
-
-    git-update-index
-    git-ls-files
-    git-diff-files
-    git-diff-index
-    git-diff-tree
-    git-rev-list
-    git-rev-parse
+  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