git/TODO

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.  Also whatever I marked "Perhaps" do not have to happen
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).

* Maybe update tutorial with a toy project that involves two or
  three developers.


Design issues
-------------

* 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.]

* Perhaps "everything in config file"?  Especially remotes/
  shortcuts.  I am modestly negative about this.


Technical (heavier)
-------------------

* 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)
------------------

* send-pack/receive-pack protocol updates, to allow the receiver
  to report what it did to the ref update requests [DONE].

* Perhaps a smarter HTTP anonymous download via CGI.

* Prepare to enable "always use symbolic refs for HEAD" patch.
  We need a timeline to force Porcelains to get ready.  Last
  time I looked at them I got an impression that gitweb was not
  ready.

* Forbid/ignore pack names that do not conform to the convention
  sha1_pack_name() assumes and reject in check_packed_git_idx()
  [In pu]

* strip leading directory from ls-tree output, to match ls-files
  output.

  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.

  [DONE, with --full-name option like ls-files]

* Any Porcelain-ish we forgot or punted to make usable from
  subdirectory?  I think the last pass caught everything and
  what are remaining are whole-tree or whole repository
  operations.

* 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.

* 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].

* Daemon --base-path does not apply automatically to whitelist
  somehow feels wrong.  If somebody cares enough, accept
  patches.


Technical (trivial)
-------------------

* Daemon --base-path forbidding user-path automatically feels
  wrong.  If somebody cares enough, accept patches.

* git-proxy should be spawned with sh -c 'command' $1 $2.

* Versioning scheme.  The next maintenance installment will be
  1.0.3 not 1.0.0c.  The next feature release would be 1.1.0 [DONE].

* Either drop supporting Debian myself or coerce patches out of
  the official maintainer [DONE -- DROPPED].

* 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.

* In a freshly created empty repository, `git fetch foo:bar`
  works OK, but `git checkout bar` afterwards does not (missing
  `.git/HEAD`).


Local Variables:
mode: text
End: