On 17.07.2017 13:42, Julian Foad wrote: > Initially I wrote that 'checkpointing' should allow committing the > result either all at once or as a corresponding series of commits. > Having thought more, I believe the use case for a series of commits > falls out of scope. > > Definitions: > > Quilt: > > Preparing a series of patches that will be applied (perhaps > committed) sequentially in a given order. > Each patch represents a self-contained logical change, likely with > its own log message. > Later patches may depend on earlier ones. > Ability to jump to any patch in the series and modify it in the > context of the earlier patches having been applied and the later ones > not. > After such a modification, updating (as in rebasing) the later > patches accordingly. > Ability to commit the series as a corresponding series of commits, > or all in one commit. > > Checkpointing: > > Saving intermediate, unfinished, working states during the > preparation of a single logical change. > The change will be committed as one revision when finished. > Changing a state that has been checkpointed may be accomplished > either by rolling back to an earlier state and then re-doing all > subsequent changes in the desired way, or by leaving that checkpoint > in place and making a further checkpoint after changing the working > state in the desired way. > Like an "undo stack", with or without "redo".
In order to use checkpoints as a sort of local commit, you do have to be able to push a series of commits to the server. You'd distinguish explicit checkpoints (with log messages) and implicit/automatic checkpoints; only the explicit ones would constitute separate commits. In order to support that, you'd have to have a way to rebase the whole checkpoint stack onto current HEAD (or at least to a non-conflicting state). Ideally you'd also support operations such as checkpoint reordering, (local) squashing, removal, etc. -- Brane
