TODO updates.
[git.git] / TODO
diff --git a/TODO b/TODO
index cc4dc34..a38f6eb 100644 (file)
--- a/TODO
+++ b/TODO
-What to expect after 0.99.5
-===========================
+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 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 ;-).
 
 
 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.
+* No pending issues at the moment.  "Revamp Tutorial" initiative
+  by Bruce Fields ongoing and things are looking better.
+
+
+Design issues
+-------------
+
+* Rehash "git commit" with various parameters to be more
+  intuitive without breaking traditinal users too much.  We need
+  to phase this in, especially if we are going to change "git
+  commit" to imply the current "git commit -a" behaviour.
+
+* "intent to add" index entries.
 
-* Link howto docs from the git.txt page. [DONE]
+* 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.
 
-* Update the SubmittingPatches document to add MUA specific
-  hints on how to disable unwanted MIME and flowed-text by
-  collecting past list postings.  Accept patches from people who
-  was hit by shiny blue bat to update the same.
+* 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.
+* Make 'format-patch' take revision limiters similar to
+  rev-list.  For example:
 
-* Update tutorial to cover shared repository style a bit more,
-  maybe with a toy project that involves two or three
-  repositories.
+               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:
 
-* Get help to properly use asciidoc in tutorial.
+       $ git format-patch ^A ^B C
 
-* Maybe justify and demonstrate an Octopus in the tutorial.  Add
-  it to the glossary.
+  Currently the closest approximation is
+
+       $ git format-patch A..C B..C
+
+  which results in the last two commits including C formatted
+  twice.
 
 
 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.
+* 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>]
+
+* 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.
+
+* 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]
 
 
 Technical (milder)
 ------------------
 
-* When the branch head pointed by $GIT_DIR/HEAD changes while
-  the index file and working tree are looking the other way
-  (e.g. somebody pushed into your repository, or you ran "git
-  fetch" to update the ref your working tree is on), "git
-  checkout" without -f gets confused.  Figure out a good way to
-  handle this. [DONE - waiting for response]
+* "git status -v" to give commit preview.
+
+* Subprojects.  I think the "bind commit" approach has been
+  outlined at sufficiently detailed level.  Maybe find time to
+  actually start prototyping it?
+
+  <7vacdzkww3.fsf@assigned-by-dhcp.cox.net>
 
-* "git commit -m" should work for initial commits and perhaps
-  merge commits as well.  Warning about merge is still a good
-  thing to do, while -m is useful in scripted non-interactive
-  use, so we need to be careful. [DONE - waiting for response]
+* Shallow clones.
 
-* Encourage concrete proposals to commit log message templates
-  we discussed some time ago.
+* Mark entries as "assume unchanged" in the index.
 
-* Bug Ryan and work with him to update send-email easier to use.
+  <Pine.LNX.4.64.0601311807470.7301@g5.osdl.org>
 
-* Look at portability fixes from Jason Riedy
+  A config item '[core] trust_stat = false' would cause to:
 
-    http://www.cs.berkeley.edu/~ejr/gits/git.git#portable 
+  - "update-index" with or without --add would mark the path
+    valid after registering.  Should we make the working tree
+    file read-only at this point?
 
-  [Looked at it.  Maybe promising.  Maybe not.]
+  - checkout-index -u would mark the path and makes the working
+    tree file read-only.
 
-* Accept patches to cause "read-tree -u" delete a directory when
-  it makes it empty.
+  - read-tree without -u would mark the path invalid.
 
-* Perhaps accept patches to introduce the concept of "patch flow
-  expressed as ref mappings" Josef has been advocating about.
+  - update-index --refresh should *not* mark up-to-date paths valid.
 
-* Perhaps accept patches to do undo/redo, but I am reluctant to
-  add commands to cover very limited use cases right now.
+  Impacts to various commands:
 
-* MIMEified applymbox to grok B and Q encodings in headers and
-  turn them into UTF-8; unwrap QP; explode multipart.
+  - update-index --refresh would ignore them.
 
-* "git cherry-pick" that applies the patch an existing commit
-  introduces in its ancestry chain, possibly using the 3-way
-  merge machinery; update rebase using the cherry-pick command.
-  Carl's redo/undo might fall out naturally from this.
+  - diff-files would say unchanged.
 
-* Redo "git revert" using 3-way merge machinery. [Done.]
+  - diff-index without --cached acts the same way as diff-index
+    --cached.
+
+* 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.
+
+  <43CC695E.2020506@codeweavers.com>
+
+* 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 smarter HTTP anonymous download via CGI.
+
+* 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.
+
+* daemon --strict-symlink.
+
+* daemon --base-path does not apply automatically to whitelist
+  somehow feels wrong.  If somebody cares enough, accept
+  patches.
+
+* 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'.  am/applymbox is _not_ the place to do it.
+
+* Allow 'git apply' to accept GNU diff 2.7 output that forgets
+  to say '\No newline' if both input ends with incomplete
+  lines.
+
+* Perhaps deal with "Files differ" (binary diff) in non C
+  locales.
+
+* Maybe grok PGP signed text/plain in applymbox as well.
+
+* 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)
+-------------------
 
-* A tool to detect, show and prune already merged topic
-  branches.
+* git-proxy should be spawned with sh -c 'command' $1 $2.
 
-* Perhaps "git branch -d" to delete a branch.
+* test scripts for the relative directory path stuff.
 
-* Enhance "git repack" to not always use --all; this would be
-  handy if the repository contains wagging heads like "pu" in
-  git.git repository.
+* In a freshly created empty repository, `git fetch foo:bar`
+  works OK, but `git checkout bar` afterwards does not (missing
+  `.git/HEAD`).
 
-* Remove "git clone-dumb-http".
+\f
+Local Variables:
+mode: text
+End: