| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
`morph merge` only worked for a small subset of cases, and has been left
to bit-rot, since we don't use it.
`morph tag` is just a `git tag` when we have petrified definitions
repository. We don't use it, nor do we need it, so it can go away rather
than take up valuable development time fixing it when requirements
change.
`old-foo` have all been superceded by newer versions and are no-longer
used.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This now means that the system morphology is not altered when chunks are
altered, so some tests had to change.
Since this uses the python warnings API, these warnings can be ignored
by running
python -W ignore:"stratum morphology" \
-W ignore:"system morphology" \
"$(which morph)" ...`
or turned into errors with
python -W error:"stratum morphology" \
-W error:"system morphology" \
"$(which morph)" ...`
|
|
This makes petrify much simpler, since adding unpetrify-ref is handled
by MorphSet.
This has the side-effect of adding unpetrify-ref when editing, but this
information is also useful for this use-case.
The edit tests now have different diffs and commits, so those have been
updated.
Also, the old merge code currently warns that now there appears to be
petrified changes, since it detects if a branch is petrified by the
presence of the unpetrify-ref field, even though the ref is not a SHA1.
The old code does not handle undoing an edit the new way, so I did not
feel it was worth attempting to comprehend it to fix this bug, which
will be later fixed by the introduction of the new merge code.
|