Re: Checkpointing

Imagine working on one larger feature (or even multiple features). You
already have created a couple of local commits, but are not yet
finished. Following use cases come to my mind:

1) some other developer commits new revisions
- it should be possible to continue working on your feature-queue
keeping it based on the old revision, but sooner or later it comes the
time to integrate the new revision(s)
- this means to create a new queue on the new revision and cherry-pick
all local commits of the old queue onto this new revision (could this be
done with purely local information or would each cherry-pick require a
possibly slow communication with the server?)
- with each cherry-pick, a conflict might occur - aborting should abort
the creation of the new queue and application of the old queue,
resulting in the deletion of the partly finished new queue keeping the
old one
- each queue should be rebased independently onto the new revisions

2) you have to make a quick-fix revision
- you need to switch from your local feature-queue to the latest
revision and fix the bug a coworker requests to get fixed
- you may now switch back to your queue to proceed with the work, but
there is a new revision now, so you should base your work sooner or
later on that revision

3) you want to rework your local commits, e.g. change order, squash some
commits, change the message
- create a new queue based on the same revision
- create new local commits by cherry-picking commits from the other
(old) queue, maybe amending some local commits
- after the new queue is ready (verify to diff it with the old queue)
the old queue can be deleted
- often enough I find it useful to be able to make one of my first
feature commits public, so the x first local commits should be possible
to be become revisions => the queue becomes shorter and based on the new
revision(s)

4) you need to fork an existing queue at any local commit
- switching to one of the local commits of your current queue you detect
that it contains a flaw
- creating now a local commit to fix would mean to first create a new
queue based on the same revision, apply all previous local commits (no
conflict risk) - the old queue would be kept

It might be useful to be able to "store" somehow one or another queue on
the server, e.g. for backup reasons, so no change is lost if my hard
disk crashes or my code fails and cleans the disk. (Creating a new, real
feature branch with revisions in the repository I don't like because
then they would be cut in stone and this would force me to create nice
and clean commits. But because we are not without error, such code will
contain back and forth changes and hence hard to read.)

As long as I'm working on a non-trivial feature/refactoring, I prefer to
have complete control over my commits, I even like to commit completely
unstable and incomplete code with Git - because I have the possibility
to clean up later.

-- 
Best regards,
Thomas Singer
On 02/07/2019 18:32, Nathan Hartman wrote:
> On Sun, Jun 30, 2019 at 11:22 AM Thomas Singer <thomas.singer_at_syntevo.com>
> wrote:
> 
>> With "rebasing" I mean, that such list of "local commits" needs to be
>> re-applied (on demand, not automatically) onto a different revision.
>> Something like a continues series of cherry-picking (with the
>> possibility to get a conflict in each step; and a possibility to
>> continue after conflict resolution or abort). This means to me, that at
>> least cherry-picking needs to be possible from a revision or a "local
>> commit".
>>
> 
> Could you describe how you would like to use this capability? E.g.,
> give an example use case?
>