TODO

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