When given --html=foo.html, a HTML file containing a table of the
current merge frontier is written to foo.html. The table contains
the classes needed to allow the accompanying imerge.css to render
it in colorful glory.
Controlled with new diagram options --color and --no-color:
--no-color forces coloring off, else --color forces coloring on, else
we turn on coloring only if stdout is a tty.
Instead of working directly with the formatting characters returned
from Block.format_diagram(), build on the semantic diagram returned
from Block.create_diagram(), and bitwise-or in additional constants
to represent the merge frontier semantically.
Then add MergeFrontier.format_diagram() to perform a similar mapping
of the semantic information into a "graphical" format. The end result
printed to the screen is identical across this refactoring.
Instead of passing formatting characters directly into
Block.create_diagram(), create the diagram using integer constants
to represent the semantic state of each node in the diagram.
Provide Block.format_diagram() for mapping the integer constants
onto a provided "legend", which provides the "graphical" (insofar
as ASCII-art can be considered such) representation of the various
states for each node in the diagram.
Also collapse Block._write() into Block.write(), since the latter
is equivalent to the former with default arguments passed.
The diagram argument to the fill_diagram() methods of MergeFrontier and
Block was never used, so remove it. Once removed, the fill_diagram()
name no longer makes much sense, since the diagram is created within
the method, and no longer passed in as an argument. Therefore, rename
the methods to create_diagram().
The docstrings of the two methods are adjusted accordingly.
When simplifying an incremental merge into a "rebase", preserve the
author info from the original commits (but update the committer info
to the person running "git-imerge simplify").
I've taken some liberties when merging this commit, integrating it
into the commit_tree() command that I recently added for backwards
compatibility reasons, and renaming the function get_commit_info() to
get_author_info().
Conflicts:
git-imerge
The subprocess module in Python 2.6 has a CalledProcessError class,
but its constructor doesn't take a third (output) argument. So don't
only pass the constructor two arguments.
Handle the automatic merges at the vertex of a block more carefully,
by merging them two ways and verifying that the two resulting trees
are identical.
When autofilling the vertex of a block, it is possible to do the merge
three ways:
1. Using the commits directly above and to the left as parents
2. Using the commits at [i1,0] and [i1-1,i2] as parents (i.e., as a
continuation of the bottom edge)
3. Using the commits at [i1,i2-1] and [0,i2] as parents (i.e., as a
continuation of the right edge)
We want the final history to be *as if* the parents were as in (1).
Formerly we were doing (1) and simply using the result. This is
incorrect because the neighboring commits do not have correct
histories. Therefore, the merge base for this merge is [0,0], and the
merge can have unnecessary conflicts.
Change to trying both (2) and (3). If both of those commits succeed
*and* if they give identical trees, then create a synthetic commit
with the parents as in (1) and use that; otherwise, fail.
MergeFrontier.remove_failure() was not doing the right thing. If
there is a conflict like this:
*******
*......
*.....X
*......
then it should attempt to split the conflicting block into two blocks
(one of which might be empty) like this:
*****||
-----++
*....|X
-----+.
but instead it is doing this:
*****|*
*----+.
*.....X
*......
which is nonsense. This could lead to an infinite loop (GitHub issue
Some environments might have a old and/or broken version of python2
installed in /usr/bin but still wish to use git-imerge. The non-broken
version of python might be loaded separately from the base operating
system image via for example environment modules [1].
So use the currently active python2 from the environment instead of
hard coding the path to /usr/bin/python2.
[1] http://modules.sourceforge.net/
These files are in the public domain, except for iepngfix.htc, which
is under LGPL 2.1+ (see notice in file).
This command adds the pristine versions of the files, so that the
small changes that I made in the files in the next commit will be
documented.
The test scripts used to assume that they were being run from a
strange place. Instead, teach them to derive the main project
directory "BASE" from $0 and
* always place the temporary directory at $BASE/t/tmp
* always run git-imerge from $BASE/git-imerge
* be more careful before deleting an old test directory.
Keep track of which commits block frontier blocker blocks. (Hmmm,
maybe the word "block" is being overused...)
This makes it possible to preserve a persistent record of which of the
blocks on the current frontier have no hope of progressing without
user interaction, and allow us to avoid some checks at every program
start.
I also think that with some extra code we could use an *unblocked*
blocker when bisecting and outlining and thereby avoid the need to
outline unblocked blocks as two blocks in many cases; i.e., instead of
filling such a block like this:
*******
*@.....
*?????.
*?????.
*......
we could fill it like this:
*******
*@????.
*?????.
*?????.
*......
and thereby avoid a lot of bookkeeping commits.
Rename MergeFrontier.add_success() to get_affected_blocker_block() and
change it to return the block that was freed up by the new merge. If
there is no such merge, raise an exception.
Generate diagram output in two stages:
* Write one string for each commit to a 2D array
* Write the array to output
Then give access to the former functionality via new fill_diagram()
methods.
