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

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

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

* 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

  we should be able to format commits 'o', without duplicates,
  by:

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

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

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

* Shallow clones.

* Mark entries as "assume unchanged" in the index.
  New option to update-index to set or drop the bit is needed.

  - update-index --no-stat paths...
  - update-index --with-stat paths...

  Also a config item '[core] trust_stat = false' would enable
  this automatically:

  - "update-index" with or without --add would mark the path
    after registering.  Should we make the working tree file
    read-only at this point?

  - checkout-index -u would mark the path and makes the working
    tree file read-only.

  Impacts to various commands:

  - update-index --refresh would ignore them.

  - diff-files would say unchanged.

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

* Prepare to enable "always use symbolic refs for HEAD" patch.
  We need a timeline to force Porcelains to get ready.  All the
  major ones should be ready now.

* 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 --no-user-dir, to make ~user still work with
  --base-path.  They ought to be independent.

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

* Use parent info in 'diff-tree --stdin'.

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

* test scripts for the relative directory path stuff.

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