TODO

   1 What to expect after 0.99.6
   2 ===========================
   3
   4 This is written in a form of to-do list for me, so if I say
   5 "accept patch", it means I do not currently plan to do that
   6 myself.  People interested in seeing it materialize please take
   7 a hint.
   8
   9
  10 Documentation
  11 -------------
  12
  13 * Accept patches from people who actually have done CVS
  14   migration and update the cvs-migration documentation.
  15   Link the documentation from the main git.txt page.
  16
  17 * Accept patches from people who were hit by shiny blue bat to
  18   update the SubmittingPatches [ONGOING].
  19
  20 * Talk about using rsync just once at the beginning when
  21   initializing a remote repository so that local packs do not
  22   need to be expanded.  I personally do not think we need tool
  23   support for this (but see below about optimized cloning).
  24
  25 * Maybe update tutorial with a toy project that involves two or
  26   three developers..
  27
  28 * Update tutorial to cover setting up repository hooks to do
  29   common tasks.
  30
  31 * Accept patches to finish missing docs.
  32
  33
  34 Technical (heavier)
  35 -------------------
  36
  37 * Tony Luck reported an unfortunate glitch in the 3-way merge.
  38   Encourage discussions to come up with a not-so-expensive way
  39   to catch the kind of ambiguities that led to his misery.
  40   [Daniel's patch looks quite promising, so is the one from
  41   Fredrik.]
  42
  43 * HPA has two projects, klibc and klibc-kbuild, that have large
  44   set of overlapping files in different paths (i.e. one has many
  45   renames from the other).  There currently is no way for git to
  46   help keep these two trees in sync, merging criss-cross between
  47   them.  The merge logic should be able to take advantage of
  48   rename/copy detection smarts git-diff-* family has.  Linus,
  49   me, and Daniel outlined a smarter merge strategy for this.
  50   Try them out.
  51
  52 * To make it easier to experiment with different merge
  53   strategies, make git-merge driver that will run merge backends
  54   for the best merge [Outlined the idea; just do it].
  55
  56 * We might want to optimize cloning with GIT native transport
  57   not to explode the pack, and store it in objects/pack instead.
  58   We would need a tool to generate an idx file out of a pack
  59   file for this.  Also this itself may turn out to be a bad
  60   idea, making the set of packs in repositories everybody has
  61   different from each other.
  62
  63 * Maybe a pack optimizer.  I am not convinced that packing all
  64   objects into a single pack and removing all the existing panck
  65   is the right way to go, since that would work against people
  66   who already have those packs.
  67
  68 * Maybe an Emacs VC backend.
  69
  70
  71 Technical (milder)
  72 ------------------
  73
  74 * Tool renames [STARTED].
  75
  76 * Have Daniel's read-tree graduate from "pu" after plugging leaks.
  77
  78 * Implement a merge backend using Daniel's read-tree.
  79
  80 * Accept Fredrik merge after renaming it (I want to name the
  81   driver 'git merge').  Suggest where to place *.py stuff --
  82   probably in $(share)/git-core/ and add Makefile entry for
  83   installation.
  84
  85 * Encourage concrete proposals to commit log message templates
  86   we discussed some time ago.
  87
  88 * Bug Martin for archimport script documentation.
  89
  90 * More portability.  I dropped a SunOS patch on the floor by
  91   somebody.
  92
  93 * Accept patches to cause "read-tree -u" delete a directory when
  94   it makes it empty.
  95
  96 * Perhaps accept patches to introduce the concept of "patch flow
  97   expressed as ref mappings" Josef has been advocating about.
  98
  99 * Perhaps accept patches to do undo/redo.
 100
 101 * Maybe grok PGP signed text/plain in applymbox as well.
 102
 103 * Perhaps a tool to revert a single file to pre-modification
 104   state?  git-cat-file blob `git-ls-files | grep foo` >foo or
 105   git-cat-file blob `git-ls-tree HEAD foo` >foo?  What should
 106   the command be called?  git-revert is taken so is
 107   git-checkout.
 108
 109 * A tool to detect, show and prune already merged topic
 110   branches.
 111
 112 * Enhance "git repack" to not always use --all; this would be
 113   handy if the repository contains wagging heads like "pu" in
 114   git.git repository.
 115
 116 * Internally split the project into non-doc and doc parts; add
 117   an extra root for the doc part and merge from it; move the
 118   internal doc source to a separate repository, like the +Meta
 119   repository; experiment if this results in a reasonable
 120   workflow, and document it in howto form if it does.
 121
 122 * Option to limit rename detection for more than N paths.
 123
 124
 125 Technical (trivial)
 126 -------------------
 127
 128 * Perhaps "git branch -d" to delete a branch.
 129
 130 * We would want test scripts for the relative directory path
 131   stuff Linus has been working on.  So far, the following
 132   commands should be usable with relative directory paths:
 133
 134     update-cache
 135     ls-files
 136     diff-files
 137     diff-cache
 138     diff-tree
 139     rev-list
 140     rev-parse
 141
 142 * In a freashly created empty repository, `git fetch foo:bar`
 143   works OK, but `git checkout bar` afterwards does not (missing
 144   `.git/HEAD`).
 145
 146 \f
 147 Local Variables:
 148 mode: text
 149 End: