Each of these old-name commands continues to invoke its
old-name counterpart on the other end.
+ - There was a discussion to move bulk of the git-* programs out
+ of /usr/bin and use /usr/lib/git; the central mechanism was
+ done, but the actual move is postponed post 1.0.
+
What to expect after 0.99.9
===========================
magically work from any subdirectory" change by Linus. It is
a good change in principle and we would like to have that
behaviour but some tool implementations I am sure are assuming
- to never run from anywhere other than the top.
+ to never run from anywhere other than the top. [Post 1.0]
* Ref namespace management. Perhaps use refs/local/ suggestion
by Linus.
Technical (milder)
------------------
+* merge-recursive needs to register conflicting paths as higher
+ stage entries in the index. For that, it first needs to
+ construct three trees whose paths are already renamed, and
+ call 3-way read-tree.
+
* Binary package split. Plan laid out and discussion mostly
- done.
+ done. [RPM side done; Debian side delegated]
+
+* User-relative paths by Andreas Ericsson. [DONE]
-* User-relative paths by Andreas Ericsson.
+* Accessing configuration variables from C and from scripts by
+ Johannes [DONE].
-* Proxing git:// connection by Paul Collins.
+* Proxing git:// connection by Paul Collins. [DONE]
* Maybe look at Cogito and see if I can help Pasky to adjust to
- the later core features? Zack Brown's "cg-seek leaving empty
- directories" problem is a good example of this.
+ the later core features?
* Perhaps detect cloning request in upload-pack and cache the
result for next cloning request until any of our refs change.
* Make rebase restartable; instead of skipping what cannot be
automatically forward ported, leave the conflicts in the work
tree, have the user resolve it, and then restart from where it
- left off [mechanism mostly done].
+ left off [DONE].
* Output full path in the "git-rev-list --objects" output, not
just the basename, and see the improved clustering results in
better packing [Tried, but did not work out well].
-* Updated git-changes-script Jeff Garzik needs [Inquiry for
- external spec sent out with a quick hack. Will know if that
- is what he needs hopefully soon].
+* Updated git-changes-script Jeff Garzik needs [Not needed --
+ pull into local or borrow temporarily with alternate object
+ directories environment variable and use normal tools].
+
+* Customizable init-db. Personally I think template mechanism
+ is good enough. Otherwise, maybe add hooks/post-init-db.
* Make sure we do reasonable thing on binary files even in
- cherry-pick and rebase.
+ cherry-pick and rebase [DONE].
+
+* Binary diff detection fails if locale set to non English; even
+ GNU diff 2.8.1 and 2.8.7 in C locale say different things. At
+ least run diff under C locale (setenv LANG=C LC_ALL=C) for
+ 1.0. It might be better to have our own binary detection
+ logic, or even our own diff output without forking an external
+ diff. [The former _might_ make sense for 1.0, but the latter
+ is post 1.0].
Technical (trivial)
* 'git lost-and-found'? Link dangling commits found by
fsck-objects under $GIT_DIR/refs/lost-found/. Then
- show-branch or gitk can be used to find any lost commit. [A
- feeler patch sent out. Very underwhelming response X-<.]
+ show-branch or gitk can be used to find any lost commit.
+ [DONE]
Do not name it /lost+found/; that would probably confuse
things that mistake it a mount point (not our code but
ko-rc are in refs/tags/).
* We would want test scripts for the relative directory path
- stuff Linus has been working on. So far, the following
- commands should be usable with relative directory paths:
-
- git-update-index
- git-ls-files
- git-diff-files
- git-diff-index
- git-diff-tree
- git-rev-list
- git-rev-parse
+ stuff Linus has been working on. Most of the C-level
+ commands should be usable with relative directory paths.
* In a freashly created empty repository, `git fetch foo:bar`
works OK, but `git checkout bar` afterwards does not (missing
projects / git.git / blobdiff