Re: Can I remove stg sync --undo ?
- From
Karl Hasselström <kha@treskal.com>
- Date
- Jul 8, 2008, 04:14 UTC
- Message-ID
- <20080708041425.GA2247@diana.vm.bytemark.co.uk>
- In-Reply-To
- <b0943d9e0807071347n17e2e09ai761b849d2d03bc9c@mail.gmail.com>
On 2008-07-07 21:47:13 +0100, Catalin Marinas wrote:
Show 19 quoted lines
> 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.
OK, then I'll write a simple test that makes sure undo and sync interact the way I imagine they should. ;-)
Show 13 quoted lines
> > 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