git.oblomov.eu Git - git/blob - 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     http://repo.or.cz/w/alt-git.git?a=blob;hb=todo;f=TODO
   8
   9 This is primarily meant for my personal reminder, but feel free
  10 to pick an item from the list and work on it.
  11
  12 ----------------------------------------------------------------
  13
  14 Recent issues
  15 -------------
  16
  17 * gitk --left-right
  18
  19 From: Linus Torvalds <torvalds@linux-foundation.org>
  20 Message-ID: <alpine.LFD.0.98.0705051524300.17381@woody.linux-foundation.org>
  21 From: Junio C Hamano <junkio@cox.net>
  22 Message-ID: <7vabwifl23.fsf@assigned-by-dhcp.cox.net>
  23
  24 * Pushing into a non-bare repository more gracefully.
  25
  26 When git-push is done to a non-bare repository and updates the
  27 branch that is currently checked out, we currently do not do
  28 anything special.
  29
  30 From: Linus Torvalds <torvalds@linux-foundation.org>
  31 Message-ID: <Pine.LNX.4.64.0704160931550.5473@woody.linux-foundation.org>
  32
  33 * git-daemon bug?
  34
  35 From: Franck Bui-Huu <vagabon.xyz@gmail.com>
  36 Message-ID: <450EABD0.1040102@innova-card.com>
  37
  38 Repeated requests against git-daemon makes it stuck under --syslog
  39
  40 [jc: does not reproduce easily for me; has anybody seen it?]
  41
  42 * Delegate gitweb part to somebody else.
  43
  44 * Use gitattributes for more things.
  45
  46  - 'precious' files that are not tracked but not
  47    build-products.  Currently people seem to put them in
  48    .gitignore, but that is not quite right, as .gitignore is
  49    meant for ignoring things that can be lost (build products,
  50    editor backup files).  "git clean -x" and "git checkout" to
  51    another branch that has a file where the current branch has a
  52    directory could lose such 'precious' files.
  53
  54  - Customized "diff -p" markers per path (Johannes, on #git
  55    2007-04-30).
  56
  57    I think it makes sense to give an extra parameter to xdiff
  58    machinery to affect how "diff -p" markers are constructed (as
  59    opposed to teach xdiff machinery to read gitattributes -- the
  60    code does not have path information at that level).  The
  61    simplest interface would be to pass a regexp and have the
  62    existing code always look for that regexp backwards.  A more
  63    complex one would involve a callback function, but I do not
  64    know if that kind of complexity is worth it.
  65
  66  - Others???
  67
  68
  69 Technical (heavier)
  70 -------------------
  71
  72 * Subproject Porcelain.
  73
  74  - recursive checkout
  75  - recursive diff
  76
  77   From: Junio C Hamano <junkio@cox.net>
  78   Message-ID: <11793556371774-git-send-email-junkio@cox.net>
  79
  80 * make merge-recursive and read-tree -u more robust when D/F
  81   conflict is involved.
  82
  83   From: Junio C Hamano <junkio@cox.net>
  84   Message-ID: <11793556371774-git-send-email-junkio@cox.net>
  85
  86 * Use blame machinery to track a single file (not path) in a finer
  87   grained way.
  88
  89 From: Linus Torvalds <torvalds@linux-foundation.org>
  90 Message-ID: <alpine.LFD.0.98.0704201554550.9964@woody.linux-foundation.org>
  91
  92 [jc: I have a fixed-up one parked in 'pu' and also outlined what
  93 other things I think are needed in my response:
  94
  95     Message-ID: <7vwt06wqv8.fsf@assigned-by-dhcp.cox.net>
  96 ]
  97
  98 Technical (milder)
  99 ------------------
 100
 101 * add 'tree' entries to the index.
 102
 103   From: Junio C Hamano <junkio@cox.net>
 104   Message-ID: <11793556371774-git-send-email-junkio@cox.net>
 105
 106 * "pure" clones, that does not know about where it was cloned
 107   from.  Specifically, no [remote "origin"] in .git/config, nor
 108   refs/remotes/origin.
 109
 110   From: Junio C Hamano <junkio@cox.net>
 111   Message-ID: <7vr6pac86g.fsf@assigned-by-dhcp.cox.net>
 112
 113 * upload-pack support to start fetching from any valid point on
 114   the history, not just published refs. (Erik W. Biederman
 115   <m164jc9ekx.fsf@ebiederm.dsl.xmission.com>)
 116
 117 * daemon --strict-symlink.
 118
 119 * Maybe grok PGP signed text/plain in applymbox as well.
 120
 121 * "git fetch" should be able to use foreign SCM import backends
 122   such as svnimport and cvsimport.
 123
 124 * "git clone" should be a thin wrapper around init/remote/fetch/checkout
 125
 126   From: Junio C Hamano <junkio@cox.net>
 127   Message-ID: <11793556371774-git-send-email-junkio@cox.net>
 128
 129 Technical (trivial)
 130 -------------------
 131
 132 * Change the "first line of commit message is special" rule to
 133   "first paragraph" and then wrap it.
 134
 135   From: Junio C Hamano <junkio@cox.net>
 136   Message-ID: <7vsla5pkug.fsf@assigned-by-dhcp.cox.net>
 137
 138   This is slightly related, but I have been wondering about the
 139   interaction with "single-liner summary, empty line and then the
 140   rest" convention and various commands in the log family.
 141
 142   Currently, --pretty=oneline and --pretty=email (hence format-patch)
 143   take and use only the first line.  I think we could change it to:
 144
 145    - take the first paragraph, where the definition of the first
 146      paragraph is "skip all blank lines from the beginning, and
 147      then grab everything up to the next empty line".
 148
 149    - replace all line breaks with a whitespace.
 150
 151   This change would not affect well-behaved commit messages that
 152   adhere to the convention, as their first paragraph always
 153   consist of a single line.  On the other hand, people from
 154   different culture can get frustrated by their commit message
 155   chomped at the first linebreak in the middle of sentence right
 156   now, which would be helped by this change.
 157
 158   Their Subject: and --pretty=oneline output would become very
 159   long and unsightly, but their commit messages are already
 160   ugly anyway, and such a change at least avoid the loss of
 161   information.
 162
 163   If we were to do this, Subject: line would most likely use
 164   RFC2822 line folding at the places where line breaks were in the
 165   original, but that goes without saying.
 166
 167   What do people think?
 168
 169 * Give --stdin to git-log, similar to git-rev-list
 170
 171 From: "Marco Costalba" <mcostalba@gmail.com>
 172 Message-ID: <e5bfff550705110413q28aef3d8k3aeb0d342eeb2016@mail.gmail.com>
 173
 174 * Update the lockfile protocol so that closing and renaming are
 175   done inside lockfile commit time.  Some filesystems do not
 176   like an open file renamed and then closed.  Come up with a
 177   patch and pass Alex for an Ack.
 178
 179 * Mbx (not mbox) support for git-mailsplit.
 180
 181 * git-clone fail .git/refs/foo (Yann Dirson <ydirson@altern.org>)
 182   <20060610225040.GA7766@nowhere.earth>
 183
 184 * git-proxy should be spawned with sh -c 'command' $1 $2.
 185
 186 [jc: should it? -- deciding if it should may not be "trivial",
 187 but if it turns out to be the right thing to do, the change
 188 itself is trivial.]
 189
 190 * Maybe a true git-proxy command that reads the first request
 191   pkt-line, and redirects the request to its real destination.
 192
 193 * test scripts for the relative directory path stuff.
 194
 195 \f
 196 Local Variables:
 197 mode: text
 198 End: