LEP: Changesets for unified working tree change tracking with first-class conflicts

[mjansson]

Summary

This proposal lets a single Lore instance carry several ongoing streams of work in one working tree. It introduces the changeset: a lightweight set of changes recorded as its own strictly linear line of history — a line that reduces to a single net change — layered over the branch the developer is on.

A developer can attach a changeset to materialize its changes in the working tree, detach it to park them off-disk, keep several attached at once, let an editor or tool checkpoint work into one continuously, and move a changeset as a unit — committing it onto the current branch, or switching to another to land it there.

One mechanism thereby covers a wide range of needs that today are unmet or served only by separate, partial workarounds: automatic personal backup of work, several work streams in flight at once, carrying work across branch switches, deferring a conflict to resolve in an orderly fashion rather than head-on, toggling changes on and off to test combinations, keeping long-lived debug or utility changes switchable, and picking up in-progress work on a developer's other machines.

Concretely, it folds three mechanisms Lore has today — dirty-file tracking, staging as the recording of commit intent, and the personal backup branch already used in UEFN — into a single concept, and on that foundation adds what Lore has never had: multiple parallel changesets in one working tree and first-class conflict handling.

[ahaczewski]

That's a very good proposal, and the way changesets are designed here solves so many Perforce issues, it is Unreal it can be done. Nice!

One nitpick: I think the proposal should explicitly state that binary or otherwise unmergeable files are changeset-membership atomic: a path may belong to at most one attached changeset at a time, hunk-level reassignment is unavailable, and any competing change to the same path is treated as an inter-changeset conflict requiring detach, reassign, or revert.

The other thing is I'm not entirely sure whether there already is a mechanism for classifying files as unmergeable, or how to tell it from the mergeable one.