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.
