Tool Renames Plan
=================
- - All non-binary commands will lose -script suffix in
- $(bindir). The source to git-foo will be either git-foo.sh
- or git-foo.perl in the source tree, and the documentation
- will be in Documentation/git-foo.txt.
-
- - The commands whose names have 'cache' to mean 'index file'
- will get 'cache' in their names replaced with 'index'. For
- git-fsck-cache and git-convert-cache, 'cache' will be
- replaced with 'objects'.
-
- - The commit walkers will have 'pull' in their names replaced
- with 'fetch'. 'git-ssh-push' will become 'git-ssh-upload'.
-
- - We continue to follow the convention to name the C source
- file that contains the main program of 'git-foo' command
- 'foo.c'. That means we will have 'fsck-objects.c', for
- example.
-
- - At this moment, I am not planning to rename the symbols used
- in programs, nor any library sources. "cache.h" will stay
- "cache.h", so does "read-cache.c". "struct cache_entry" and
- "ce_match_stat()" will keep their names. We _might_ want to
- rename them in later rounds but not right now.
-
- - In 0.99.7, all renamed commands will have symbolic links in
+ - In 0.99.7, all renamed commands have symbolic links in
$(bindir) so that old names continue to work. These backward
compatible names will not appear in documentation. The main
documentation, git(7) will talk about the new names but would
mention their old names as historical notes. Old environment
names defined in gitenv() will also be removed in this release.
- - In 0.99.8, we do not install these backward compatible
+ - In 0.99.8, we will not install these backward compatible
symbolic links in $(bindir) anymore. The Makefile will have
a target to remove old symlinks from $(DESTDIR)$(bindir) you
can run manually to help you clean things up.
- The timeframe for this is around Oct 1st, but I could be
- talked into delaying the symlink removal if Porcelain people
- find this schedule too tight.
+ As a notable exception, git-ssh-push and git-ssh-pull pair is
+ not going away within this timeframe, if ever. Each of these
+ old-name commands continues to invoke its old-name
+ counterpart on the other end. Updating to 0.99.8 on one end
+ of the connection does not requier the other end to update at
+ the same time.
+
+ The timeframe for this is around Oct 1st.
What to expect after 0.99.7
* Maybe update tutorial with a toy project that involves two or
three developers..
+* Document octopus [Linus prodded me again; DONE].
+
* Update tutorial to cover setting up repository hooks to do
common tasks.
* Accept patches to finish missing docs.
+* Accept patches to talk about "Whoops, it broke. What's
+ next?".
+
+* Accept patches to make formatted tables in asciidoc to work
+ well in both html and man pages (see git-diff(1)).
+
Technical (heavier)
-------------------
* Maybe an Emacs VC backend.
+* 'git split-projects'? This requires updated 'git-rev-list' to
+ skip irrelevant commits.
+
Technical (milder)
------------------
+* Revisit 'git-merge'. It probably was a mistake to "loop to
+ choose the best one", since what is best is not ill defined to
+ begin with. This would make it a lot straightforward to
+ loosen the tree cleanliness requirements to the acceptable
+ level.
+
* The recent commit walker safety patch may be too cautious and
appears to take forever when cloning. This may even be
infinitely looping in the code lifted from the old rev-list --
- needs to be taken a look at [DONE INITIAL CUT].
+ needs to be taken a look at [DONE -- and redone very nicely by
+ Sergey].
* Encourage concrete proposals to commit log message templates
we discussed some time ago.
* Accept patches for more portability.
* strcasestr() in mailinfo. We may need compat/strcasestr.c;
- this is bugging OpenBSD folks.
+ this is bugging OpenBSD folks [DONE].
* Accept patches to cause "read-tree -u" delete a directory when
it makes it empty.
* Maybe grok PGP signed text/plain in applymbox as well.
* Perhaps a tool to revert a single file to pre-modification
- state? git-cat-file blob `git-ls-files | grep foo` >foo or
- git-cat-file blob `git-ls-tree HEAD foo` >foo? What should
- the command be called? git-revert is taken so is
- git-checkout.
+ state? People with BK background know this operation as
+ 'clean'. 'git checkout [-f] ent [path...]' was suggested by
+ Matthias Urlichs which sounds a natural extention to what the
+ command currently does.
* Enhance "git repack" to not always use --all; this would be
handy if the repository contains wagging heads like "pu" in
just the basename, and see the improved clustering results in
better packing [Tried, but did not work out well].
-* Remove obsolete commands [READY].
+* Remove obsolete commands [DONE].
* Option to limit rename detection for more than N paths [READY].
Technical (trivial)
-------------------
-* 'git add --recursive'?
+* Stop installing the old-name symlinks.
+
+* 'git add --recursive' [DONE]
* 'git merge-projects'?