Re: Checkpointing

[Nathan Hartman <ha...@gmail.com>]

On Sun, Jun 30, 2019 at 11:22 AM Thomas Singer <th...@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?

Re: Checkpointing

[Thomas Singer <th...@syntevo.com>]

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 <th...@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?
>