Can I remove stg sync --undo ?

> Is it OK if I remove it? "stg undo" will allow you to undo the whole
> command, or, in case of conflicts, either the whole command or just
> the last conflicting push. But it does not allow for undoing the last
> refresh (whether it succeeded or not). I don't know how refresh is
> used, so I can't really tell if "stg undo" is currently insufficient.

> 2008/7/2 Karl Hasselström <kha@treskal.com>:
>
> > I'm preparing a patch that removes all the old --undo flags, and
> > discovered that stg sync has an --undo flag backed by
> > stack.undo_refresh().
>
> The current --undo flag restores the state of the patch before a
> successful sync. If the sync fails with a conflict and it needs a
> refresh after resolving, I think it loses the previous state of the
> patch and just restores to whatever it was before the refresh.

> The sync performs three operations - push, merge and refresh (if the
> refresh is automatic after merge, it doesn't update the backup
> information since it was done by merge).
>
> If merge fails, the refresh is manual after solving the conflicts. I
> suspect this will be recorded as a separate step for undo

> On 2008-07-03 23:02:28 +0100, Catalin Marinas wrote:
>> The sync performs three operations - push, merge and refresh (if the
>> refresh is automatic after merge, it doesn't update the backup
>> information since it was done by merge).
>>
>> If merge fails, the refresh is manual after solving the conflicts. I
>> suspect this will be recorded as a separate step for undo
>
> Yeah, the new undo stuff will currently handle sync just like e.g.
> push and pop: write one log entry when the command's all done, plus
> one extra just before the conflicting push if there is one. So you can
> always undo the entire command; and in case of conflicts, you also
> have the option of undoing just the conflicting push. Is this enough
> for sync?

> 2008/7/4 Karl Hasselström <kha@treskal.com>:
>
> > On 2008-07-03 23:02:28 +0100, Catalin Marinas wrote:
> >
> > > The sync performs three operations - push, merge and refresh (if
> > > the refresh is automatic after merge, it doesn't update the
> > > backup information since it was done by merge).
> > >
> > > If merge fails, the refresh is manual after solving the
> > > conflicts. I suspect this will be recorded as a separate step
> > > for undo
> >
> > Yeah, the new undo stuff will currently handle sync just like e.g.
> > push and pop: write one log entry when the command's all done,
> > plus one extra just before the conflicting push if there is one.
> > So you can always undo the entire command; and in case of
> > conflicts, you also have the option of undoing just the
> > conflicting push. Is this enough for sync?
>
> There are two operations that can conflict for sync - pushing a
> patch and the actual sync'ing, i.e. a three-way merge with the patch
> to be synchronised with (kind of fold).

> > > (BTW, is resolved take into account for undo?).
> >
> > Hmmm, what do you mean by "resolved"?
>
> The current resolved command - the clearing of the conflicting
> entries in the index.

> On 2008-07-04 23:05:11 +0100, Catalin Marinas wrote:
>
>> 2008/7/4 Karl Hasselström <kha@treskal.com>:
>>
>> > On 2008-07-03 23:02:28 +0100, Catalin Marinas wrote:
>> >
>> > > The sync performs three operations - push, merge and refresh (if
>> > > the refresh is automatic after merge, it doesn't update the
>> > > backup information since it was done by merge).
>> > >
>> > > If merge fails, the refresh is manual after solving the
>> > > conflicts. I suspect this will be recorded as a separate step
>> > > for undo
>> >
>> > Yeah, the new undo stuff will currently handle sync just like e.g.
>> > push and pop: write one log entry when the command's all done,
>> > plus one extra just before the conflicting push if there is one.
>> > So you can always undo the entire command; and in case of
>> > conflicts, you also have the option of undoing just the
>> > conflicting push. Is this enough for sync?
>>
>> There are two operations that can conflict for sync - pushing a
>> patch and the actual sync'ing, i.e. a three-way merge with the patch
>> to be synchronised with (kind of fold).
>
> My guess is that conflicts of the first type would work out of the box
> (i.e. they'd get an extra log entry) while conflicts of the second
> type would not.

>> > > (BTW, is resolved take into account for undo?).
>> >
>> > Hmmm, what do you mean by "resolved"?
>>
>> The current resolved command - the clearing of the conflicting
>> entries in the index.
>
> With just "stg undo" (or reset or redo), you get the usual
> new-infrastructure check about dirty index and working tree (the whole
> index must be clean, and the parts of the worktree we need to touch
> must be clean). Which prevents you from undoing a conflicting push,
> for example.
>
> With the --hard flag, any uncleanliness in index or worktree simply
> gets zapped (just like with git reset --hard). I'm not 100% happy with
> this -- what I'd really like is to zap only the files that we need to
> touch. But I haven't figured out a good way to do that.

> 2008/7/5 Karl Hasselström <kha@treskal.com>:
>
> > On 2008-07-04 23:05:11 +0100, Catalin Marinas wrote:
> >
> > > There are two operations that can conflict for sync - pushing a
> > > patch and the actual sync'ing, i.e. a three-way merge with the
> > > patch to be synchronised with (kind of fold).
> >
> > My guess is that conflicts of the first type would work out of the
> > box (i.e. they'd get an extra log entry) while conflicts of the
> > second type would not.
>
> I don't really care as long as I can get back to the patch state
> before running the sync command if anything goes wrong. So, one undo
> level would be enough.
>
> > We need a sync undo test.
>
> Yes but not sure what how undo would behave in this situation yet.

> > With just "stg undo" (or reset or redo), you get the usual
> > new-infrastructure check about dirty index and working tree (the
> > whole index must be clean, and the parts of the worktree we need
> > to touch must be clean). Which prevents you from undoing a
> > conflicting push, for example.
> >
> > With the --hard flag, any uncleanliness in index or worktree
> > simply gets zapped (just like with git reset --hard). I'm not 100%
> > happy with this -- what I'd really like is to zap only the files
> > that we need to touch. But I haven't figured out a good way to do
> > that.
>
> OK, not much to comment here, it's your implementation :-).