2008/7/5 Karl Hasselström <kha@xxxxxxxxxxx>: > On 2008-07-04 23:05:11 +0100, Catalin Marinas wrote: > >> 2008/7/4 Karl Hasselström <kha@xxxxxxxxxxx>: >> >> > 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. > We need a sync undo test. Yes but not sure what how undo would behave in this situation yet. >> > > (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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
