From: Karl Hasselström <hidden> Date: 2016-06-15 22:44:52
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().
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.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
Hi Karl,
Sorry for the delay, I've been really busy recently.
2008/7/2 Karl Hasselström [off-list ref]:
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.
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.
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 (BTW, is
resolved take into account for undo?).
--
Catalin
From: Karl Hasselström <hidden> Date: 2016-06-15 22:44:53
On 2008-07-03 23:02:28 +0100, Catalin Marinas wrote:
Sorry for the delay, I've been really busy recently.
No problem.
2008/7/2 Karl Hasselström [off-list ref]:
quoted
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
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?
(BTW, is resolved take into account for undo?).
Hmmm, what do you mean by "resolved"?
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
On 2008-07-03 23:02:28 +0100, Catalin Marinas wrote:
quoted
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).
quoted
(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.
--
Catalin
From: Karl Hasselström <hidden> Date: 2016-06-15 22:44:53
On 2008-07-04 23:05:11 +0100, Catalin Marinas wrote:
2008/7/4 Karl Hasselström [off-list ref]:
quoted
On 2008-07-03 23:02:28 +0100, Catalin Marinas wrote:
quoted
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.
We need a sync undo test.
quoted
quoted
(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.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
On 2008-07-04 23:05:11 +0100, Catalin Marinas wrote:
quoted
2008/7/4 Karl Hasselström [off-list ref]:
quoted
On 2008-07-03 23:02:28 +0100, Catalin Marinas wrote:
quoted
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.
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.
quoted
quoted
quoted
(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.
OK, not much to comment here, it's your implementation :-).
--
Catalin
From: Karl Hasselström <hidden> Date: 2016-06-15 22:44:54
On 2008-07-07 21:47:13 +0100, Catalin Marinas wrote:
2008/7/5 Karl Hasselström [off-list ref]:
quoted
On 2008-07-04 23:05:11 +0100, Catalin Marinas wrote:
quoted
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.
quoted
We need a sync undo test.
Yes but not sure what how undo would behave in this situation yet.
OK, then I'll write a simple test that makes sure undo and sync
interact the way I imagine they should. ;-)
quoted
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 :-).
But you too get to live with the design decisions ...
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle