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