TODO

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


Cogito-only stuff:


Pre-1.0 stuff:

* Tutorial
	(We have crash courses, one for version control newbies is missing -
	it should be included in the source as well, though.)

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

* "Volatile" branches
	* Make one-time merges easier by enabling cg-update to take
	  URIs directly, not only head names.

* Support for mass-cloning all remote refs at once
	* Requires first multi-origin support (if origin is a dir, fall
	  back to origin/master).
	* Interface: cg-clone -a
	* Implement this using refs/remote/ so that the branches won't
	  get mixed together and we can trace new/disappearing branches
	  in the parent repository sanely

* Support for remotes/
	More powerful 'n stuff than branches/, ya know.
	LIKELY NOT - parsing those would be just annoying, we will probably
	just dump directly to supporting [remote] in .git/config. There will
	need to be a conversion script though.

* Push new tags automagically
	(With the same logic as when fetching - push tags which reference
	objects that are already pushed.)
	(First there really needs to be a way to have private tags. I think
	just tag names starting by a dot would do.)

* 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"
	* Somehow show the list of commits getting merged
	-- post 1.0 --
	* Vim-merging
	* cg-resolve: resolving swiss-army knife, see msgid:
		<20060924171246.GY13132@pasky.or.cz>

* 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-commit enhancements
	* Force the user to confirm his credentials for the first time
	* 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.)
	* Call git-fmt-merge-msg when committing a merge

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

* Support all the Git hooks


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
	* Possibility to quickly show patches for commits

* Graphical commit/merge tool

* cg-annotate, cg-bisect

* Cogito's friendly patch stack handling (frontending stgit?)
	Not sure yet if the UI improvement would be substantial

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

* Private tags support

* Empty directories handling
	Directories should be first-class index objects, not implicit.
	Perhaps.

* Common templates
	The discussion about templates sharing among the toolkits somewhat
	died out.


Long term:

* Proper renaming recording
	We need to do something about it. For now, at least properly follow
	renames everywhere and have tree renames detection.

	In the long term, either some Linus-envisioned smart moves detection
	needs to be done (I'm still skeptical) or persistent file ids. One
	trouble is keeping merge from traversing all the history.

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

		Jun 16 Jon Seymour [PATCH 1/1] [PROPOSAL] Add a module (repo-log.c) to log repository events.