What comes on my mind but it isn't able to hold it all. Unsorted.


Cogito-only stuff:


Before the following minor version release:

* Deal with [PATCH] cogito: use locale date_fmt in obtaining default date format

* cg-mv


Pre-1.0 stuff:
(Note that I'm not sure whether the mail-related improvements to
cg-*patch should be pre-1.0.)

* 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.

* "Volatile" branches
	Properly follow branches which can rebase (do not do tree
	merges but "fastforwards").

* 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)
	* Support for various GIT's "merge strategies"
	-- post 1.0 --
	* 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-switch
	Full-fledged multibranch support - allow switching between
	several branches in a single working tree, as well as creating
	new ones (much alike git checkout -b), possibly based on
	an arbitrary commit. (You should be also able to clone remote
	branch at a particular commit.)

* 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):
	Preparing patch series, frontending git-request-fetch,
	interfacing with email directly...

* cg-patch improvements
	* Again, an email interface - frontend to applymbox and stuff,
	autocommitting, sucking commit messages from the patch...
	* Dealing with renames and stuff

* cg-commit enhancements
	* Things coming to git-commit:
		* 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.
		* -s,--signoff to automatically append a signoff line of
		  yours to the patch.
	-- post 1.0 --
	* Patch-altering cg-commit
		You can already alter the list of files to be committed,
		let's optionally show the patch and let you alter it, too.

* cg-push over HTTP

* cg-Xfetchprogress showing smooth progress for packfiles

* Offload most of cg-object-id to git-rev-parse


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.
