I use the undo feature quite a bit, and I think it's important that it continues to work across moves. But the log and undo will be per-branch, I suppose.
2014-04-03 15:54 GMT+02:00 Erik Carstensen <[email protected]>: > Hi, > > Sorry about that. Here's the py file, and also a test. > > I mimicked the test for 'pick', and I'm not quite happy with it: The test > is very sequential (each subtest depends on all previous subtests to > succeed), and upon a failure the output isn't very useful. Are there any > tools in your test framework that I can use to improve the test? Are there > any existing tests I can read and learn from? > > By the way, two more implementation notes: > - If one tries to allow moving a patch from a branch to itself, it will > effectively be popped, but also renamed. The rename comes from some strange > aspect of the Patches class: stgit will not realize that a patch is deleted > within the same stgit process, so make_patch_name will find a new name. > - I chose to let any conflicts abort the entire transaction, to avoid some > headache. > > By the way: While looking at this, I noticed that delete (from which most > of my implementation is derived) contains some code that doesn't work the > way it seems to be intended: > def allow_conflicts(trans): > # Allow conflicts if the topmost patch stays the same. > if stack.patchorder.applied: > return (trans.applied > and trans.applied[-1] == stack.patchorder.applied[-1]) > else: > return not trans.applied > > Looks like the author wants delete to abort the transaction if there is a > merge conflict below the stack top. However, it does not. If your series is > A B C, and you delete A, yielding a conflict when pushing B, then the > command ends up with B's conflict in the working tree. > > > > On Thu, Apr 3, 2014 at 3:34 PM, Catalin Marinas > <[email protected]>wrote: > >> Erik, >> >> On 31 March 2014 23:12, Erik Carstensen <[email protected]> wrote: >> > Here is an implementation of stg move. >> >> Is there a way to decompile a .pyc file? It's easier if you sent the >> .py one directly ;). >> >> > Some notes: >> > - I didn't use a transaction for creating patches in the new branch, >> because >> > patch creation cannot fail (and transactions don't span multiple >> branches). >> >> I think that's fine, Karl know more about this. >> >> > - Branches are given with explicit options --from and --to. Specifying >> none >> > would be a strange way of expressing pop, and likely a mistake, so I >> made >> > that an error. >> >> So we won't have default options. Fine by me. >> >> > - The patch log is not copied to the new branch. I never used patch >> logs, so >> > I don't know about your expectations there. >> >> I don't use them much either. It can be added afterwards if we find a way. >> >> > - Is there a function to pick a name for a patch? I couldn't find one, >> so I >> > rewrote the logic instead (find_unique_name). It would be better to use >> an >> > existing one, or to promote mine to a library if none exists. >> >> There is make_patch_name() in stgit/utils.py. See __create_patch() in >> stgit/commands/imprt.py for an example on how to use this. >> >> Catalin >> > > -- David Kågedal
_______________________________________________ stgit-users mailing list [email protected] https://mail.gna.org/listinfo/stgit-users
