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
Received on 2017-07-17 14:50:29 CEST