Minor update to Subpro.txt
[git.git] / TODO
diff --git a/TODO b/TODO
index 919ee3a..0d86e47 100644 (file)
--- a/TODO
+++ b/TODO
@@ -17,35 +17,46 @@ if ever -- only if somebody cares enough and submits a clean
 patch, perhaps ;-).
 
 
-Documentation
--------------
-
-* 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).
+UI
+--
 
-* Maybe update tutorial with a toy project that involves two or
-  three developers.
+* Make "git branch -d foo" while on foo branch suggest "maybe
+  you want to go back to 'master'?"
 
 
 Design issues
 -------------
 
+* "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.
 
-* 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.]
+* Doing a merge in a separate directory?
+
+* Make 'format-patch' take revision limiters similar to
+  rev-list.  For example:
+
+               A                  C
+       ....---x---o---o---x---o---o
+                          /
+                         /
+                        /
+       ....---x---o---o
+               B
 
-* Perhaps "everything in config file"?  Especially remotes/
-  shortcuts.  I am modestly negative about this.
+  we should be able to format commits 'o', without duplicates,
+  by:
 
-* Perhaps "setting umask from git_config()"?  I am modestly
-  negative about this.
+       $ git format-patch ^A ^B C
+
+  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)
@@ -68,34 +79,37 @@ Technical (heavier)
 
   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)
 ------------------
 
-* send-pack/receive-pack protocol updates, to allow the receiver
-  to report what it did to the ref update requests.
+* Shallow clones.
+
+* Encourage competition between annotate vs blame.  Maybe come
+  up with some nontrivial test cases.
 
-* Perhaps a smarter HTTP anonymous download via CGI.
+* Subprojects.  I think the "bind commit" approach has been
+  outlined at sufficiently detailed level.  Maybe find time to
+  actually start prototyping it?
 
-* Prepare to enable "always use symbolic refs for HEAD" patch.
-  We need a timeline to force Porcelains to get ready.
+  <7vacdzkww3.fsf@assigned-by-dhcp.cox.net>
 
-* Forbid/ignore pack names that do not conform to the convention
-  sha1_pack_name() assumes and reject in check_packed_git_idx().
+* 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.
 
-* strip leading directory from ls-tree output, to match ls-files
-  output.
+  <43CC695E.2020506@codeweavers.com>
 
-  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.
+* 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>
 
 * 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.
@@ -103,40 +117,27 @@ Technical (milder)
 
 * 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'.
-
-* 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)
 -------------------
 
-* Versioning scheme.  The next maintenance installment will be
-  1.0.3 not 1.0.0c.  The next feature release would be 1.1.0.
-
-* Either drop supporting Debian myself or coerce patches out of
-  the official maintainer.
+* git-proxy should be spawned with sh -c 'command' $1 $2.
 
-* 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.
+* 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`).