2008/7/5 Karl Hasselström <kha@treskal.com>:
quoted text
> 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.

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 text
> We need a sync undo test.

Yes but not sure what how undo would behave in this situation yet.

quoted text
>> > > (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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html