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
    http://repo.or.cz/w/alt-git.git?a=blob;hb=todo;f=TODO

This is primarily meant for my personal reminder, but feel free
to pick an item from the list and work on it.

----------------------------------------------------------------

Recent issues
-------------

* parse-remote.sh has POSIXLY incorrect shell construct.

Message-ID: <20070505080313.GA12170@gondor.apana.org.au>

* Use 'git diff' not 'git diff-tree' in merge and rebase

From: James Bowes <jbowes@dangerouslyinc.com>
Message-ID: <1178398134288-git-send-email-jbowes@dangerouslyinc.com>

* gitk --left-right

From: Linus Torvalds <torvalds@linux-foundation.org>
Message-ID: <alpine.LFD.0.98.0705051524300.17381@woody.linux-foundation.org>
From: Junio C Hamano <junkio@cox.net>
Message-ID: <7vabwifl23.fsf@assigned-by-dhcp.cox.net>

* Pushing into a non-bare repository more gracefully.

When git-push is done to a non-bare repository and updates the
branch that is currently checked out, we currently do not do
anything special.

From: Linus Torvalds <torvalds@linux-foundation.org>
Message-ID: <Pine.LNX.4.64.0704160931550.5473@woody.linux-foundation.org>

* git-daemon bug?

From: Franck Bui-Huu <vagabon.xyz@gmail.com>
Message-ID: <450EABD0.1040102@innova-card.com>

Repeated requests against git-daemon makes it stuck under --syslog

[jc: does not reproduce easily for me; has anybody seen it?]


* AsciiDoc 8 would break our documentation.

From: Stefan Richter <stefanr@s5r6.in-berlin.de>
Message-ID: <4523EC14.6070806@s5r6.in-berlin.de>

AsciiDoc 8 does not grok documents written for AsciiDoc 7 out of
the box.

[jc: limbo?]

* Delegate gitweb part to somebody else.

* Use gitattributes for more things.

 - 'precious' files that are not tracked but not
   build-products.  Currently people seem to put them in
   .gitignore, but that is not quite right, as .gitignore is
   meant for ignoring things that can be lost (build products,
   editor backup files).  "git clean -x" and "git checkout" to
   another branch that has a file where the current branch has a
   directory could lose such 'precious' files.

 - Customized "diff -p" markers per path (Johannes, on #git
   2007-04-30).

   I think it makes sense to give an extra parameter to xdiff
   machinery to affect how "diff -p" markers are constructed (as
   opposed to teach xdiff machinery to read gitattributes -- the
   code does not have path information at that level).  The
   simplest interface would be to pass a regexp and have the
   existing code always look for that regexp backwards.  A more
   complex one would involve a callback function, but I do not
   know if that kind of complexity is worth it.

 - Others???


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

* Subproject Porcelain.

 - recursive checkout
 - recursive diff

  From: Junio C Hamano <junkio@cox.net>
  Message-ID: <11793556371774-git-send-email-junkio@cox.net>

* make merge-recursive and read-tree -u more robust when D/F
  conflict is involved.

  From: Junio C Hamano <junkio@cox.net>
  Message-ID: <11793556371774-git-send-email-junkio@cox.net>

* Use blame machinery to track a single file (not path) in a finer
  grained way.

From: Linus Torvalds <torvalds@linux-foundation.org>
Message-ID: <alpine.LFD.0.98.0704201554550.9964@woody.linux-foundation.org>

[jc: I have a fixed-up one parked in 'pu' and also outlined what
other things I think are needed in my response:

    Message-ID: <7vwt06wqv8.fsf@assigned-by-dhcp.cox.net>
]

Technical (milder)
------------------

* add 'tree' entries to the index.

  From: Junio C Hamano <junkio@cox.net>
  Message-ID: <11793556371774-git-send-email-junkio@cox.net>

* "pure" clones, that does not know about where it was cloned
  from.  Specifically, no [remote "origin"] in .git/config, nor
  refs/remotes/origin.

  From: Junio C Hamano <junkio@cox.net>
  Message-ID: <7vr6pac86g.fsf@assigned-by-dhcp.cox.net>

* upload-pack support to start fetching from any valid point on
  the history, not just published refs. (Erik W. Biederman
  <m164jc9ekx.fsf@ebiederm.dsl.xmission.com>)

* daemon --strict-symlink.

* Maybe grok PGP signed text/plain in applymbox as well.

* "git fetch" should be able to use foreign SCM import backends
  such as svnimport and cvsimport.

* "git clone" should be a thin wrapper around init/remote/fetch/checkout

  From: Junio C Hamano <junkio@cox.net>
  Message-ID: <11793556371774-git-send-email-junkio@cox.net>

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

* Change the "first line of commit message is special" rule to
  "first paragraph" and then wrap it.

  From: Junio C Hamano <junkio@cox.net>
  Message-ID: <7vsla5pkug.fsf@assigned-by-dhcp.cox.net>

  This is slightly related, but I have been wondering about the
  interaction with "single-liner summary, empty line and then the
  rest" convention and various commands in the log family.

  Currently, --pretty=oneline and --pretty=email (hence format-patch)
  take and use only the first line.  I think we could change it to:

   - take the first paragraph, where the definition of the first
     paragraph is "skip all blank lines from the beginning, and
     then grab everything up to the next empty line".

   - replace all line breaks with a whitespace.

  This change would not affect well-behaved commit messages that
  adhere to the convention, as their first paragraph always
  consist of a single line.  On the other hand, people from
  different culture can get frustrated by their commit message
  chomped at the first linebreak in the middle of sentence right
  now, which would be helped by this change.

  Their Subject: and --pretty=oneline output would become very
  long and unsightly, but their commit messages are already
  ugly anyway, and such a change at least avoid the loss of
  information.

  If we were to do this, Subject: line would most likely use
  RFC2822 line folding at the places where line breaks were in the
  original, but that goes without saying.

  What do people think?

* Give --stdin to git-log, similar to git-rev-list

From: "Marco Costalba" <mcostalba@gmail.com>
Message-ID: <e5bfff550705110413q28aef3d8k3aeb0d342eeb2016@mail.gmail.com>

* Update the lockfile protocol so that closing and renaming are
  done inside lockfile commit time.  Some filesystems do not
  like an open file renamed and then closed.  Come up with a
  patch and pass Alex for an Ack.

* Mbx (not mbox) support for git-mailsplit.

* git-clone fail .git/refs/foo (Yann Dirson <ydirson@altern.org>)
  <20060610225040.GA7766@nowhere.earth>

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

[jc: should it? -- deciding if it should may not be "trivial",
but if it turns out to be the right thing to do, the change
itself is trivial.]

* Maybe a true git-proxy command that reads the first request
  pkt-line, and redirects the request to its real destination.

* test scripts for the relative directory path stuff.


Local Variables:
mode: text
End: