TODO

   1 What comes on my mind but it isn't able to hold it all. Unsorted.
   2
   3 Cogito-only stuff:
   4
   5
   6 Pre-1.0 stuff:
   7
   8 * Tutorial
   9         (We have crash courses, one for version control newbies is missing -
  10         it should be included in the source as well, though.)
  11
  12 * Show only first 12 (or so) nibbles of the hashes everywhere
  13         Even this might be too much, but more than this is really useless
  14         for anyone remotely human. And it's less scary, too.
  15
  16 * "Volatile" branches
  17         * Make one-time merges easier by enabling cg-update to take
  18           URIs directly, not only head names.
  19
  20 * Support for mass-cloning all remote refs at once
  21         * Requires first multi-origin support (if origin is a dir, fall
  22           back to origin/master).
  23         * Interface: cg-clone -a
  24         * Implement this using refs/remote/ so that the branches won't
  25           get mixed together and we can trace new/disappearing branches
  26           in the parent repository sanely
  27
  28 * Support for remotes/
  29         More powerful 'n stuff than branches/, ya know.
  30         LIKELY NOT - parsing those would be just annoying, we will probably
  31         just dump directly to supporting [remote] in .git/config. There will
  32         need to be a conversion script though.
  33
  34 * Push new tags automagically
  35         (With the same logic as when fetching - push tags which reference
  36         objects that are already pushed.)
  37         (First there really needs to be a way to have private tags. I think
  38         just tag names starting by a dot would do.)
  39
  40 * Better merging
  41         * Handle all possible conflicts
  42         * Make sure the user resolved the conflicts
  43           (if possible without requiring him to manually indicate that)
  44         * Support for various GIT's "merge strategies"
  45         * Somehow show the list of commits getting merged
  46         -- post 1.0 --
  47         * Vim-merging
  48         * cg-resolve: resolving swiss-army knife, see msgid:
  49                 <20060924171246.GY13132@pasky.or.cz>
  50
  51 * cg-mkpatch overhaul
  52         cg-mkpatch was overlooked for too long, while it could do a huge
  53         number of cool things (after some cleanups, and probably factoring
  54         out the common parts of cg-mkpatch, cg-log and cg-diff):
  55         Frontending git-request-fetch, interfacing with email directly...
  56
  57 * cg-commit enhancements
  58         * Force the user to confirm his credentials for the first time
  59         * Possibly verify the patch being committed against
  60           whitespace errors and stuff; hooks are good for this too,
  61           but I think it's good to have internal support for the
  62           basic stuff. (Get inspired in git-commit.)
  63         * Call git-fmt-merge-msg when committing a merge
  64
  65 * cg-shelf - shelve changes temporarily
  66         This saves your current uncommitted changes, removes them from the
  67         tree, opens editor with the diff of those changes and lets you edit
  68         it; then it applies only the diff on the tree and lets you commit
  69         it or whatever. After committing, cg-unshelf or cg-shelf -u or
  70         whatever will restore the state of the tree before cg-shelf was
  71         called.
  72
  73 * Support all the Git hooks
  74
  75
  76 Post 1.0:
  77
  78 * Subprojects
  79         Support a GIT project inside a GIT project:
  80
  81                 x/.git
  82                 x/foo/bar/.git
  83                 x/foo/bar/baz/.git
  84                 x/quux/zot/.git
  85
  86         That means cg-update working recursively and cg-add'n'stuff
  87         checking if there isn't another .git along the path of its
  88         argument.
  89
  90         Needs more thought, especially wrt. fetching and merging
  91         recursive semantics.
  92
  93 * Comfortable cg-log
  94         Probably make it a real terminal application, not just less
  95         backend.
  96
  97         * Somehow switch between summary and full output
  98         * Possibility to quickly show patches for commits
  99
 100 * Graphical commit/merge tool
 101
 102 * cg-annotate, cg-bisect
 103
 104 * Cogito's friendly patch stack handling (frontending stgit?)
 105         Not sure yet if the UI improvement would be substantial
 106
 107 * More comfortable history rewriting
 108         * Make it possible to do rebase-merge easily, rebasing local
 109           changes against new remote head; OTOH, perhaps we just need
 110           to advertise StGIT more...
 111         * Easier recommitting - if I need to uncommit or change some
 112           commit not at the top, let me more easily uncommit, change it
 113           and recommit the rest on the top.
 114
 115           This is encouraging history rewriting which is bad as soon
 116           as you publish your changes, but not before; I believe it's
 117           good to offer people ways to keep their history tidy if you
 118           also educate them not to do it after they publish it.
 119
 120 * Revisions numbering
 121         An alternative way to identify revisions - by their sequential
 122         number from the root, after merge-sorted.
 123
 124         Needs more thought.
 125
 126
 127 * Rewrite in some other language
 128         csh? Postscript? Befunge?
 129
 130 * Make Cogito agnostic to the underlying layer
 131         Actually, I start to miss Cogito's convenient interface a lot when
 132         working with other systems, and my fingers are already trained for
 133         the cg-commands. But this is a very long-term goal and will take
 134         a good deal of thought and work.
 135
 136 * World domination
 137         Make sure that as many projects as possible use GIT, and in
 138         particular that everyone uses Cogito! ;-)
 139
 140
 141
 142 Stuff partially or fully involving Core GIT:
 143
 144
 145 Short term:
 146
 147 * Unnamed remote branches
 148         Pull from an URI without cg-branch-add'ing it first.
 149         See Pasky's mail.
 150
 151 * Private tags support
 152
 153 * Empty directories handling
 154         Directories should be first-class index objects, not implicit.
 155         Perhaps.
 156
 157 * Common templates
 158         The discussion about templates sharing among the toolkits somewhat
 159         died out.
 160
 161
 162 Long term:
 163
 164 * Proper renaming recording
 165         We need to do something about it. For now, at least properly follow
 166         renames everywhere and have tree renames detection.
 167
 168         In the long term, either some Linus-envisioned smart moves detection
 169         needs to be done (I'm still skeptical) or persistent file ids. One
 170         trouble is keeping merge from traversing all the history.
 171
 172 * Better than three-way merging
 173         Perhaps pcdv merge, let's see how will that turn out.
 174
 175         Three-way merge silently gets some cases wrong, and an army of
 176         experimental VCSes developers is devising better merge algorithms
 177         for us. ;-)
 178
 179         (pcdv merge is actually probably very similar to how the BK merge
 180         works.)
 181
 182 * Cherrypicking support
 183         At least "partial" cherrypicking support, with changing head IDs.
 184         Merge up to the first dropped revision, rebase and merge on...
 185
 186         Needs more thought.
 187
 188 * Revision journal
 189         I envision each head having a revision journal - list of all preceding
 190         revisions in their merge order.
 191
 192         There are two motivations. The first is possibility of fast and
 193         setupless dumb server transport. But more importantly, git-rev-list
 194         does not scale if you want to sort it by anything but date, and you
 195         definitively want - I think the date order is confusing and e.g.
 196         for cg-mkpatch simply wrong and you really need merge order instead.
 197         But that requires to load all the history, then order it, and that
 198         means that it takes to crunch through the whole history even when
 199         showing the tip of cg-log. And that is not going to scale to
 200         thousands of revisions - it already takes 2s (20s for cold cache!)
 201         for the current Cogito/git repositories, which is too long for
 202         a quick cg-log peek.
 203
 204         So instead, every time you commit, the new revision is appended
 205         to the revision journal of the given head, and when you fetch the
 206         head, you bring the remote revision journal along. When you merge,
 207         all the new revisions are appended between the previous head and
 208         the merge head - that gives you the merge order.
 209
 210         Well, if you want to append to it, you want new revisions at the end.
 211         If you want to fetch it, you want the new revisions at the start.
 212         So I think the journal should look like
 213
 214                 .git/revlist/master/0001
 215                 .git/revlist/master/0002
 216                 ...
 217
 218         where each file contains some 1024 revisions or so, with the new
 219         ones at the end.
 220
 221         Needs more thought. See also
 222
 223                 Jun 16 Jon Seymour [PATCH 1/1] [PROPOSAL] Add a module (repo-log.c) to log repository events.
 224
 225 Test.
 226