Minor update to Subpro.txt
[git.git] / TODO
diff --git a/TODO b/TODO
index 20dfbd0..0d86e47 100644 (file)
--- a/TODO
+++ b/TODO
@@ -6,178 +6,138 @@ 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.8, we will still install the backward compatible
-   symbolic links in $(bindir).  These will however be removed
-   before 1.0 happens.
-
-   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.
-
-
-What to expect after 0.99.8
-===========================
+What to expect from now on
+==========================
 
 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 ;-).
+
+
+UI
+--
 
+* Make "git branch -d foo" while on foo branch suggest "maybe
+  you want to go back to 'master'?"
 
-Documentation
+
+Design issues
 -------------
 
-* 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.
+* "intent to add" index entries?
+
+* Plug-in file-level merges.  On the other hand, we may not even
+  need this; just tell people to run "xxdiff -U" on the working
+  tree files.
+
+* Doing a merge in a separate directory?
 
-* 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).
+* Make 'format-patch' take revision limiters similar to
+  rev-list.  For example:
 
-* Maybe update tutorial with a toy project that involves two or
-  three developers..
+               A                  C
+       ....---x---o---o---x---o---o
+                          /
+                         /
+                        /
+       ....---x---o---o
+               B
 
-* Update tutorial to cover setting up repository hooks to do
-  common tasks.
+  we should be able to format commits 'o', without duplicates,
+  by:
 
-* Accept patches to finish missing docs.
+       $ git format-patch ^A ^B C
 
-* Accept patches to talk about "Whoops, it broke.  What's
-  next?".
+  Currently the closest approximation is
 
-* Accept patches to make formatted tables in asciidoc to work
-  well in both html and man pages (see git-diff(1)).
+       $ git format-patch A..C B..C
+
+  which results in the last two commits including C formatted
+  twice.
 
 
 Technical (heavier)
 -------------------
 
-* 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.
-
-* Git daemon, when deployed at kernel.org, might turn out to be
-  quite a burden, since it needs to generate customized packs
-  every time a new request comes in.  It may be worthwhile to
-  precompute some packs for popular sets of heads downloaders
-  have and serve that, even if that could give more than the
-  client asks for in some cases.  We will know about this soon
-  enough.
-
 * 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>]
 
 * Maybe a pack optimizer.
 
-* Maybe an Emacs VC backend.
+  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.
 
-* '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.
+  This needs a matching smart on the dumb protocol downloader.
 
 
 Technical (milder)
 ------------------
 
-* Encourage concrete proposals to commit log message templates
-  we discussed some time ago.
+* Shallow clones.
 
-* Accept patches to cause "read-tree -u" delete a directory when
-  it makes it empty.
+* Encourage competition between annotate vs blame.  Maybe come
+  up with some nontrivial test cases.
 
-* Perhaps accept patches to introduce the concept of "patch flow
-  expressed as ref mappings" Josef has been advocating about.
+* Subprojects.  I think the "bind commit" approach has been
+  outlined at sufficiently detailed level.  Maybe find time to
+  actually start prototyping it?
 
-* Perhaps accept patches to do undo/redo.
+  <7vacdzkww3.fsf@assigned-by-dhcp.cox.net>
 
-* Perhaps accept patch to optionally allow '--fuzz' in
-  'git-apply'.
+* Decide what to do about rebase applied to merged head.  One
+  extreme is to allow rebase if "rev-list ours..theirs" gives
+  anything.  This loosens the current merge-base based approach.
+  The other extreme is to refuse rebase if "rev-list
+  theirs..ours" contains any merge commit, which was discussed
+  on the list.
 
-* Allow 'git apply' to accept GNU diff 2.7 output that forgets
-  to say '\No newline' if both input ends with incomplete
-  lines.
+  <43CC695E.2020506@codeweavers.com>
 
-* Maybe grok PGP signed text/plain in applymbox as well.
+* Decide what the right thing to do upon an empty merge commit,
+  when both branches happen to have obtained the same set of
+  changes through different history.  Not recording such keeps
+  the history simpler, and the next merge would soon create a
+  true merge commit anyway, but this does not feel quite right.
+
+  <20060114021800.4688.qmail@web31803.mail.mud.yahoo.com>
 
-* 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.
+* 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.
 
-* Enhance "git repack" to not always use --all; this would be
-  handy if the repository contains wagging heads like "pu" in
-  git.git repository.
+* daemon --strict-symlink.
 
-* 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.
+* daemon --base-path does not apply automatically to whitelist
+  somehow feels wrong.  If somebody cares enough, accept
+  patches.
 
-* 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.
+* Perhaps detect cloning request in upload-pack and cache the
+  result for next cloning request until any of our refs change.
 
-* 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].
+* Perhaps deal with "Files differ" (binary diff) in non C
+  locales.
 
-* Updated git-changes-script Jeff Garzik needs [Inquiry for
-  external spec sent out with a quick hack.  Will know if that
-  is what he needs soon enough].
+* Maybe grok PGP signed text/plain in applymbox as well.
 
 
 Technical (trivial)
 -------------------
 
-* short SHA1 naming is not enforcing uniqueness.  Should fix.
-
-* 'git repack' can be DOSed.  Should fix.
-
-* Stop installing the old-name symlinks [POSTPONED].
-
-* '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-proxy should be spawned with sh -c 'command' $1 $2.
 
-    git-update-index
-    git-ls-files
-    git-diff-files
-    git-diff-index
-    git-diff-tree
-    git-rev-list
-    git-rev-parse
+* test scripts for the relative directory path stuff.
 
-* In a freashly created empty repository, `git fetch foo:bar`
+* In a freshly created empty repository, `git fetch foo:bar`
   works OK, but `git checkout bar` afterwards does not (missing
   `.git/HEAD`).