Convert the TODO to markdown

Author: mhagger

TODO.md

@@ -0,0 +1,116 @@
+# Ideas for things to do
+
+## Bugs
+
+* Find some bugs and fix them :-)
+
+* Check that the capstone merge in a block outline is merged correctly.
+
+    * Since the ancestry of its two parents is incomplete, Git would probably try to do a recursive merge. See if we can somehow do better without filling in the whole diagram.
+
+    * Compare the merges that would come from continuing each side of the outline, and verify that they are identical.
+
+
+## Convenience features
+
+* Add a two-argument form of the `start` and `init` commands to specify both branches in one go. (Or maybe not, if we want to leave the way open to supporting octipus merges!) Maybe `--onto=X` like rebase?
+
+* Improve the handling of log messages. Incorporate log messages from manual merge conflicts into suggested log messages for the simplified commits.
+
+* Allow the user to specify which conflict they would like to resolve next, and set it up for them.
+
+* Allow the user to block certain merges, meaning that they should never be skipped over or merged automatically.
+
+* Add a `git imerge pause` that puts an imerge on hold and resets the working copy to a reasonable state.
+
+* Allow the user to specify a test that is run automatically after each automatic merge, (à la `git bisect run`).
+
+
+## New merge goals and styles
+
+* Add a `--goal=sparse` option that retains all of the conflicted merges and enough intermediate history to connect them.
+
+* Add an option that allows the user to resolve conflicts in larger chunks; for example, add a rebase-with-history-type merge where each branch commit is merged directly to its final location on the last master commit. (Perhaps `--conflicts={pairwise|fewest}`.)
+
+* Permit switching between goal/conflict choices when they are meaningful while prohibiting nonsensical ones.
+
+
+## Collaboration
+
+* Add `git imerge push REMOTE` to push the status of an in-progress merge to REMOTE.
+
+* Add `git imerge pull REMOTE` to pull the current state of an incremental merge from REMOTE.
+
+* Add some kind of `fetch`-like functionality that stores the result into a remote namespace.
+
+* The analogue of "non-fast-forward" for incremental merges is different than for other references. A `push`/`pull` should be prohibited if:
+
+    * Any of the branches is updated in a non-fast-forward fashion.
+
+    * Any commit `I1-I2` is updated (at all!) when there is an existing commit `I1'-I2'` with `I1' >= I1` and `I2' >= I2`.
+
+    * As a safety precaution, the DAG of the retrieved merges should probably be checked for self-consistency (see `git imerge fsck` below).
+
+* Add smarter ways to reconcile two versions of an in-progress merge that are not fast-forwards of each other. Probably this should work with two arbitrary local merges (one of which is probably from a remote).
+
+
+## Flexibility
+
+* Allow commits to be skipped over when merging if, for example, they are broken (analogous to `git bisect skip`). This should be allowed when an imerge is being initialized and also after an imerge is in progress.
+
+* Allow arbitrary manual merge commits to be recorded, and be smarter about how such commits are integrated.
+
+* Allow recorded merges to be retroactively rejected, adjusting subsequent merges accordingly.
+
+    * In first version, just discard all commits that depended on it.
+
+    * In later versions, salvage parts of the subsequent merges when possible.
+
+
+### Relax `--first-parent` limitation
+
+* Allow recursive merges: if one of the `--first-parent` merges is itself a merge, maybe it can be "exploded" into individual commits and these commits merged with the second branch as part of the first merge or as a subsidiary merge.
+
+* Allow more complicated topologies in the two branches to be merged, and somehow form the appropriate Cartesian product of their commits with the correct ancestry.
+
+
+## Tools
+
+* `git imerge info` -- show a detailed, human-readable summary of all intermediate commits related to this imerge.
+
+* `git imerge parse M-N` -- show SHA-1 of the specified merge if it has been done. Maybe also `git imerge parse NAME/M-N`.
+
+* `git imerge show M-N` -- show more, human-readable info about the specified imerge.
+
+* `git imerge list -v` -- add more information to the display; for example, the goals, status, etc. of each imerge.
+
+* `git imerge status` -- show the current imerge status (issue #22). If the user has been asked to do a merge, show the log messages for the two original commits again.
+
+
+## Miscellaneous
+
+* Add a command `git imerge fsck` (for lack of a better name) that checks the consistency of the intermediate commits (especially their DAG).
+
+* Maybe expand diagram to 2x2 characters per merge, to make room for more information (e.g., block boundaries could go in the interstices).
+
+* Maybe fix PPM output.
+
+* Maybe keep a record of all merge attempts, successful and failed.
+
+* When running subprocesses, set a more specific value to environment variable `GIT_IMERGE` reflecting exactly what git-imerge is doing at the time (e.g., 'autofill', 'automerge', etc). See issue #17.
+
+* Add better tools and hints for getting out of a screwed-up merge attempt (see, e.g., issue #29).
+
+
+## Testing
+
+* Add a tool that can create two branches with conflicts at arbitrary places. (This is pretty easy--if commit I1-I2 should conflict, then make commits I1 and I2 both create a file `conflict-i1-i2` with differing contents.
+
+* Test adjacent conflicts in various places.
+
+* Cook up some way to make conflicts that unexpectedly appear and disappear when merged as part of a block vs. pairwise. (Maybe this can be done using commits involving file renames followed by the addition of replacements.) Test such scenarios.
+
+
+## GUI
+
+* Maybe add a web interface (implementing using Python's built-in webserver) would be easiest.