From 7ca3d9d71ff982965d6a9e5f0ee2492ce977cdae Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Tue, 24 Jul 2007 21:31:33 -0700 Subject: [PATCH] TODO updates --- TODO | 87 +++++------------------------------------------------------- 1 file changed, 6 insertions(+), 81 deletions(-) diff --git a/TODO b/TODO index 95dfc6fec0..688b8f3def 100644 --- a/TODO +++ b/TODO @@ -14,34 +14,6 @@ to pick an item from the list and work on it. Recent issues ------------- -* gitweb patches (bunch of them) - -From: Matt McCutchen -Subject: [PATCH] gitweb: snapshot cleanups & support for offering multiple formats -Message-ID: <1183053733.6108.0.camel@mattlaptop2> - -Subject: [PATCH] gitweb: make search form generate pathinfo-style URLs -Message-ID: <1183057027.6108.4.camel@mattlaptop2> - -Subject: [PATCH] gitweb: make "No commits" in project list gray, not bold green -Message-ID: <1183068922.6108.8.camel@mattlaptop2> - -From: Miklos Vajna -Subject: [PATCH] gitweb: prefer git_get_project_owner() over get_file_owner() -Message-ID: <20070703221122.GI32766@genesis.frugalware.org> - -From: Michael Hendricks -Subject: [PATCH] gitweb: configurable width for the projects list Description column -Message-ID: <11835958082458-git-send-email-michael@ndrix.org> - - -* switching branches when b changes between symlink and directory in a/b/c - -From: Pierre Habouzit -Subject: [BUG (or misfeature?)] git checkout and symlinks -Message-ID: <20070704203541.GA13286@artemis.corp> - - * cherry-pick unexpected conflicts From: Gerrit Pape @@ -49,18 +21,14 @@ Subject: Re: unexpected git-cherry-pick conflict Date: Wed, 13 Jun 2007 13:43:35 +0000 Message-ID: <20070613134336.13661.qmail@c61f4fed932273.315fe32.mid.smarden.org> -* git-apply -R --whitespace=warn +* 3way merge still has D/F conflict problems -From: Daniel Barkalow -Message-ID: -Subject: Minor bug in git-apply's patch-cleaning +Subject: [RFH] 3way still has D/F conflict problems... +Date: Mon, 23 Jul 2007 00:22:51 -0700 +Message-ID: <7vejizmvn8.fsf@assigned-by-dhcp.cox.net> -* gitk --left-right - -From: Linus Torvalds -Message-ID: -From: Junio C Hamano -Message-ID: <7vabwifl23.fsf@assigned-by-dhcp.cox.net> +I am punting on unpack-trees related D/F issues for 1.5.3. We +might end up rewriting read-tree after the release. * Pushing into a non-bare repository more gracefully. @@ -90,12 +58,6 @@ Repeated requests against git-daemon makes it stuck under --syslog another branch that has a file where the current branch has a directory could lose such 'precious' files. - - Customized "diff -p" markers per path. - - From: Linus Torvalds - Subject: Re: [PATCH] Per-path attribute based hunk header selection. - Message-ID: - - Others??? @@ -162,43 +124,6 @@ Technical (milder) Technical (trivial) ------------------- -* Change the "first line of commit message is special" rule to - "first paragraph" and then wrap it. - - From: Junio C Hamano - 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"