merge: Support conflict resolution

[olsen232]

In general, two branches can be merged using sno merge. However, if there are conflicts, the sno merge operation moves the branch into a merging state, instead of completing normally.

Although there is some support for viewing and resolving conflicts when in this state, it is not yet adequate to actually complete a merge which has conflicts. To have basic but adequate support, we need the following:

• sno resolve should accept arbitrary resolutions to conflicts, not just one of the pre-existing versions
• sno status should show that we are in a merging state
• various other commands shouldn't be possible from within a merging state, unless the user exits the merging state first with sno merge --abort
• sno merge --continue should exit the merging state, if no more unresolved conflicts remain

[craigds]

Should sno resolve handle interactive resolving, for 0.4?

[olsen232]

Will wait to see what people comment on the design. Various types of conflicts or ways of resolving them might be important enough to be part of 0.4
The only one I'm pretty certain will make it in is sno resolve <feature_id> --geojson=<feature_geojson>, which is needed mostly for edit/edit conflicts.

[olsen232]

• sno merge --continue should exit the merging state, if no more unresolved conflicts remain - done at Support git merge --continue #94

Remaining:

• sno resolve should accept arbitrary resolutions to conflicts, not just one of the pre-existing versions
• sno status should show that we are in a merging state
• various other commands shouldn't be possible from within a merging state, unless the user exits the merging state first with sno merge --abort

[olsen232]

• sno status should show that we are in a merging state - done at Make sno status give info about ongoing merge #98
• various other commands shouldn't be possible from within a merging state, unless the user exits the merging state first with sno merge --abort - done at Lock commands when repo is in merging state. #97

Remaining:

• sno resolve should accept arbitrary resolutions to conflicts, not just one of the pre-existing versions

[olsen232]

• sno resolve should accept arbitrary resolutions to conflicts, not just one of the pre-existing versions - in review at Add support for arbitrary conflict resolutions #101

There is a never-ending list of other features that would be nice-to-have, but may or may not be a requirement for 0.4:

More ways to resolve:

• add support for resolving add/add conflicts by renaming one of the features automatically
• add support for auto-generating and then viewing / accepting resolutions to edit/edit conflicts, in the case that no field was edited in both branches

Better geojson resolves:

• sno conflicts --geojson doesn't produce valid geojson because it isn't flat
• no way to use sno conflicts to show less than all the conflicts at once
• (related to previous two) - no easy way to generate a geojson file containing all the existing versions of a conflict, to use as a template to create a resolution to the conflict

Multiple resolves at once, etc:

• sno resolve should accept table:23 as an alias for table:fid=23
• sno conflicts / sno resolve should accept multiple feature IDs at once
• sno conflicts / sno resolve should accept feature ID patterns, eg table_A:edit/edit
• bring back interactive mode for sno resolve

Miscellaneous:

• sno conflicts --text could use some more formatting (eg better labels for ancestor/ours/theirs), maybe colored highlights on changed fields
• some commands should be (at least partially) reactivated during merge. eg sno show / sno diff?
• working copy should probably be locked during merge, if this is possible
• merge message should be editable
• sno merge --continue should support --json output
• get latest pygit2 and
  a) turn off rename detection until this is better supported
  b) use IndexEntry instead of MergeIndex.Entry