TODO

   1 The GIT To-Do File
   2 ==================
   3
   4   The latest copy of this document is found at
   5
   6     http://kernel.org/git/?p=git/git.git;a=blob;hb=todo;f=TODO
   7
   8
   9 Tool Renames Plan
  10 =================
  11
  12  - In 0.99.7, all renamed commands have symbolic links in
  13    $(bindir) so that old names continue to work.  These backward
  14    compatible names will not appear in documentation.  The main
  15    documentation, git(7) will talk about the new names but would
  16    mention their old names as historical notes.  Old environment
  17    names defined in gitenv() will also be removed in this release.
  18
  19  - In 0.99.8, we will not install these backward compatible
  20    symbolic links in $(bindir) anymore.  The Makefile will have
  21    a target to remove old symlinks from $(DESTDIR)$(bindir) you
  22    can run manually to help you clean things up.
  23
  24    As a notable exception, git-ssh-push and git-ssh-pull pair is
  25    not going away within this timeframe, if ever.  Each of these
  26    old-name commands continues to invoke its old-name
  27    counterpart on the other end.  Updating to 0.99.8 on one end
  28    of the connection does not requier the other end to update at
  29    the same time.
  30
  31    The timeframe for this is around Oct 1st.
  32
  33
  34 What to expect after 0.99.7
  35 ===========================
  36
  37 This is written in a form of to-do list for me, so if I say
  38 "accept patch", it means I do not currently plan to do that
  39 myself.  People interested in seeing it materialize please take
  40 a hint.
  41
  42
  43 Documentation
  44 -------------
  45
  46 * Accept patches from people who actually have done CVS
  47   migration and update the cvs-migration documentation.
  48   Link the documentation from the main git.txt page.
  49
  50 * Accept patches from people who were hit by shiny blue bat to
  51   update the SubmittingPatches.
  52
  53 * Talk about using rsync just once at the beginning when
  54   initializing a remote repository so that local packs do not
  55   need to be expanded.  I personally do not think we need tool
  56   support for this (but see below about optimized cloning).
  57
  58 * Maybe update tutorial with a toy project that involves two or
  59   three developers..
  60
  61 * Document octopus [Linus prodded me again; DONE].
  62
  63 * Update tutorial to cover setting up repository hooks to do
  64   common tasks.
  65
  66 * Accept patches to finish missing docs.
  67
  68 * Accept patches to talk about "Whoops, it broke.  What's
  69   next?".
  70
  71 * Accept patches to make formatted tables in asciidoc to work
  72   well in both html and man pages (see git-diff(1)).
  73
  74
  75 Technical (heavier)
  76 -------------------
  77
  78 * Tony Luck reported an unfortunate glitch in the 3-way merge.
  79   Encourage discussions to come up with a not-so-expensive way
  80   to catch the kind of ambiguities that led to his misery.
  81   [Deathmatch between Daniel's and Fredrik's ongoing.]
  82
  83 * HPA has two projects, klibc and klibc-kbuild, that have large
  84   set of overlapping files in different paths (i.e. one has many
  85   renames from the other).  There currently is no way for git to
  86   help keep these two trees in sync, merging criss-cross between
  87   them.  The merge logic should be able to take advantage of
  88   rename/copy detection smarts git-diff-* family has.  Linus,
  89   me, and Daniel outlined a smarter merge strategy for this.
  90   Try them out.
  91
  92 * We might want to optimize cloning with GIT native transport
  93   not to explode the pack, and store it in objects/pack instead.
  94   We would need a tool to generate an idx file out of a pack
  95   file for this.  Also this itself may turn out to be a bad
  96   idea, making the set of packs in repositories everybody has
  97   different from each other.
  98
  99 * Libification.  There are many places "run once" mentality is
 100   ingrained in the management of basic data structures, which
 101   need to be fixed.
 102
 103 * Maybe a pack optimizer.
 104
 105 * Maybe an Emacs VC backend.
 106
 107 * 'git split-projects'?  This requires updated 'git-rev-list' to
 108   skip irrelevant commits.
 109   Message-ID: <Pine.LNX.4.63.0509221617300.23242@iabervon.org>
 110
 111 * Look at libified GNU diff CVS seems to use, or libxdiff.
 112
 113
 114 Technical (milder)
 115 ------------------
 116
 117 * Use 'git-update-ref' in the scripts [DONE].
 118
 119 * Use symbolic refs in .git/HEAD.  Should we do that everywhere
 120   while honoring the symlinked HEAD in the existing repositories
 121   for backward compatibility, or just only when 'ln -s' fails?
 122   [DONE].
 123
 124 * Revisit 'git-merge'.  It probably was a mistake to "loop to
 125   choose the best one", since what is best is not ill defined to
 126   begin with.  This would make it a lot straightforward to
 127   loosen the tree cleanliness requirements to the acceptable
 128   level [DONE].
 129
 130 * The recent commit walker safety patch may be too cautious and
 131   appears to take forever when cloning.  This may even be
 132   infinitely looping in the code lifted from the old rev-list --
 133   needs to be taken a look at [DONE -- and redone very nicely by
 134   Sergey].
 135
 136 * Encourage concrete proposals to commit log message templates
 137   we discussed some time ago.
 138
 139 * Accept patches for more portability.
 140
 141   * strcasestr() in mailinfo.  We may need compat/strcasestr.c;
 142     this is bugging OpenBSD folks [DONE, thanks to Linus and
 143     others].
 144
 145   * Solaris portability [ONGOING, thanks to Patrick Mauritz,
 146     Peter Eriksen and Sean from sympatico].
 147
 148 * Accept patches to cause "read-tree -u" delete a directory when
 149   it makes it empty.
 150
 151 * Perhaps accept patches to introduce the concept of "patch flow
 152   expressed as ref mappings" Josef has been advocating about.
 153
 154 * Perhaps accept patches to do undo/redo.
 155
 156 * Perhaps accept patch to optionally allow '--fuzz' in
 157   'git-apply'.
 158
 159 * Allow 'git apply' to accept GNU diff 2.7 output that forgets
 160   to say '\No newline' if both input ends with incomplete
 161   lines.
 162
 163 * Maybe grok PGP signed text/plain in applymbox as well.
 164
 165 * Perhaps a tool to revert a single file to pre-modification
 166   state?  People with BK background know this operation as
 167   'clean'.  'git checkout [-f] ent [path...]' was suggested by
 168   Matthias Urlichs which sounds a natural extention to what the
 169   command currently does.
 170
 171 * Enhance "git repack" to not always use --all; this would be
 172   handy if the repository contains wagging heads like "pu" in
 173   git.git repository.
 174
 175 * Internally split the project into non-doc and doc parts; add
 176   an extra root for the doc part and merge from it; move the
 177   internal doc source to a separate repository, like the +Meta
 178   repository; experiment if this results in a reasonable
 179   workflow, and document it in howto form if it does.
 180
 181 * Make rebase restartable; instead of skipping what cannot be
 182   automatically forward ported, leave the conflicts in the work
 183   tree, have the user resolve it, and then restart from where it
 184   left off.
 185
 186 * Output full path in the "git-rev-list --objects" output, not
 187   just the basename, and see the improved clustering results in
 188   better packing [Tried, but did not work out well].
 189
 190 * Remove obsolete commands [DONE].
 191
 192 * Option to limit rename detection for more than N paths [DONE].
 193
 194 * Option to show only status and name from diff [DONE].
 195
 196 * What to name the 'master' version between 0.99.7 and 0.99.8
 197   and still not break binary distribution folks?  0.99.7z?
 198   Pasky gave me a good one: 0.99.7.GIT [DONE]
 199
 200 * Listing more than one head on the Pull: line of .git/remotes/
 201   allows you to make Octopus -- is it useful?  Probabaly not.
 202   Either adopt "only the first head is used for the merge by
 203   default if taken from .git/remotes/ file", or "list heads to
 204   merge on a separate Merge: line" proposal.  I already have the
 205   code to do the former, so... [DONE, open for improvement
 206   patches but not just suggestions nor complaints.]
 207
 208
 209 Technical (trivial)
 210 -------------------
 211
 212 * Usher SSL enhancements to http-fetch from Nick Hengeveld into
 213   a shape acceptable by everybody [DONE].
 214
 215 * Require tk 2.4 in the spec file [DONE].
 216
 217 * show-branch naming heads is buggy [DONE].
 218
 219 * Stop installing the old-name symlinks [DONE].
 220
 221 * 'git merge-projects'?
 222
 223 * 'git clone' does not check things out [DONE].
 224
 225 * 'git lost-and-found'?  Link dangling commits found by
 226   fsck-objects under $GIT_DIR/refs/lost-found/.  Then
 227   show-branch or gitk can be used to find any lost commit. [A
 228   feeler patch sent out. Very underwhelming response X-<.]
 229
 230   Do not name it /lost+found/; that would probably confuse
 231   things that mistake it a mount point (not our code but
 232   somebody else's).
 233
 234 * Add simple globbing rules to git-show-branch so that I can
 235   say 'git show-branch --heads "ko-*"' (ko-master, ko-pu, and
 236   ko-rc are in refs/tags/).
 237
 238 * We would want test scripts for the relative directory path
 239   stuff Linus has been working on.  So far, the following
 240   commands should be usable with relative directory paths:
 241
 242     git-update-index
 243     git-ls-files
 244     git-diff-files
 245     git-diff-index
 246     git-diff-tree
 247     git-rev-list
 248     git-rev-parse
 249
 250 * In a freashly created empty repository, `git fetch foo:bar`
 251   works OK, but `git checkout bar` afterwards does not (missing
 252   `.git/HEAD`).
 253
 254 \f
 255 Local Variables:
 256 mode: text
 257 End: