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