What comes on my mind but it isn't able to hold it all. Unsorted. Cogito-only stuff: Pre-1.0 stuff: (Note that I'm not sure whether the mail-related improvements to cg-*patch should be pre-1.0.) * Support for mass-cloning all remote refs at once Requires first multi-origin support (if origin is a dir, fall back to origin/master). * Tutorial * Cogito homepage Reference documentation + Jonas' asciidoc'd README + tutorial = http://git.or.cz/cogito/ * Merge Dan Holmsand's cg-diff and cg-log work It's big rewritish diffs, not all changes are good, but most of it is cool stuff and it's a pity it stood unmerged so far. Includes merge-order cg-log and cg-diff checking for renames. * Support cg-clone -a for cloning all branches * Show only first 12 (or so) nibbles of the hashes everywhere Even this might be too much, but more than this is really useless for anyone remotely human. And it's less scary, too. * Note that this requires that cg-object-id will be a frontend to git-rev-parse so that we can properly autocomplete packed objects' names. * "Volatile" branches * Make one-time merges easier by enabling cg-update to take URIs directly, not only head names. * Support for remotes/ More powerful 'n stuff than branches/, ya know. * Better merging * Handle all possible conflicts * Make sure the user resolved the conflicts (if possible without requiring him to manually indicate that) -- post 1.0 -- * Support for various GIT's "merge strategies" * Somehow show the list of commits getting merged * Vim-merging * Always do three-way merge Always perform three-way merge instead of applying patches - when fast-forwarding trees, uncommitting, etc. * cg-mkpatch overhaul cg-mkpatch was overlooked for too long, while it could do a huge number of cool things (after some cleanups, and probably factoring out the common parts of cg-mkpatch, cg-log and cg-diff): Frontending git-request-fetch, interfacing with email directly... * cg-patch improvements * Again, an email interface - frontend to applymbox and stuff... * Dealing with renames and stuff * cg-tag enhancements * Provide the same -m and editor and stdin interface as cg-commit; the shared stuff should be libraryized. * cg-commit enhancements * Possibly verify the patch being committed against whitespace errors and stuff; hooks are good for this too, but I think it's good to have internal support for the basic stuff. (Get inspired in git-commit.) * cg-shelf - shelve changes temporarily This saves your current uncommitted changes, removes them from the tree, opens editor with the diff of those changes and lets you edit it; then it applies only the diff on the tree and lets you commit it or whatever. After committing, cg-unshelf or cg-shelf -u or whatever will restore the state of the tree before cg-shelf was called. Post 1.0: * Subprojects Support a GIT project inside a GIT project: x/.git x/foo/bar/.git x/foo/bar/baz/.git x/quux/zot/.git That means cg-update working recursively and cg-add'n'stuff checking if there isn't another .git along the path of its argument. Needs more thought, especially wrt. fetching and merging recursive semantics. * Comfortable cg-log Probably make it a real terminal application, not just less backend. * Somehow switch between summary and full output * Pickaxe * Possibility to quickly show patches for commits * Graphical commit/merge tool * cg-annotate * More comfortable history rewriting * Make it possible to do rebase-merge easily, rebasing local changes against new remote head; OTOH, perhaps we just need to advertise StGIT more... * Easier recommitting - if I need to uncommit or change some commit not at the top, let me more easily uncommit, change it and recommit the rest on the top. This is encouraging history rewriting which is bad as soon as you publish your changes, but not before; I believe it's good to offer people ways to keep their history tidy if you also educate them not to do it after they publish it. * Revisions numbering An alternative way to identify revisions - by their sequential number from the root, after merge-sorted. Needs more thought. * Rewrite in some other language csh? Postscript? Befunge? * Make Cogito agnostic to the underlying layer Actually, I start to miss Cogito's convenient interface a lot when working with other systems, and my fingers are already trained for the cg-commands. But this is a very long-term goal and will take a good deal of thought and work. * World domination Make sure that as many projects as possible use GIT, and in particular that everyone uses Cogito! ;-) Stuff partially or fully involving Core GIT: Short term: * Unnamed remote branches Pull from an URI without cg-branch-add'ing it first. See Pasky's mail. * Tags Clean up, fix and git-core-ize tags fetching; private tags need to be supported first. * Empty directories handling Directories should be first-class index objects, not implicit. * Common templates The discussion about templates sharing among the toolkits somewhat died out. Long term: * Proper renaming recording Seriously, guys. This needs to be done and I'm only not bringing it up on the mailing list since we have enough other trouble for now. My current preferred solution of this is an "edge" object which would describe the edge between two commits; containing only "rename" lines for now. Parent line format would change to parent COMMITID [edge:EDGEID] * Better than three-way merging Perhaps pcdv merge, let's see how will that turn out. Three-way merge silently gets some cases wrong, and an army of experimental VCSes developers is devising better merge algorithms for us. ;-) (pcdv merge is actually probably very similar to how the BK merge works.) * Cherrypicking support At least "partial" cherrypicking support, with changing head IDs. Merge up to the first dropped revision, rebase and merge on... Needs more thought. * Revision journal I envision each head having a revision journal - list of all preceding revisions in their merge order. There are two motivations. The first is possibility of fast and setupless dumb server transport. But more importantly, git-rev-list does not scale if you want to sort it by anything but date, and you definitively want - I think the date order is confusing and e.g. for cg-mkpatch simply wrong and you really need merge order instead. But that requires to load all the history, then order it, and that means that it takes to crunch through the whole history even when showing the tip of cg-log. And that is not going to scale to thousands of revisions - it already takes 2s (20s for cold cache!) for the current Cogito/git repositories, which is too long for a quick cg-log peek. So instead, every time you commit, the new revision is appended to the revision journal of the given head, and when you fetch the head, you bring the remote revision journal along. When you merge, all the new revisions are appended between the previous head and the merge head - that gives you the merge order. Well, if you want to append to it, you want new revisions at the end. If you want to fetch it, you want the new revisions at the start. So I think the journal should look like .git/revlist/master/0001 .git/revlist/master/0002 ... where each file contains some 1024 revisions or so, with the new ones at the end. Needs more thought.