2008/9/18 Karl Hasselström <kha@xxxxxxxxxxx>: > On 2008-09-17 17:09:46 +0100, Catalin Marinas wrote: > >> I'm still confused by this and I don't think your new flag would >> help. The meaning of stop_before_conflict is that it won't push the >> conflicting patch but actually leave the stack with several patches >> pushed or popped. >> >> What I want for sink (and float afterwards) is by default to cancel >> the whole transaction if there is a conflict and revert the stack to >> it's original state prior to the "stg sink" command. > > Ah, OK. Then I think you want something like this: > > try: > trans.reorder_patches(applied, unapplied, hidden, iw) > except transaction.TransactionHalted: > if not options.conflict: > trans.abort(iw) > raise common.CmdException( > 'Operation rolled back -- would result in conflicts') > return trans.run(iw) I tried this before but trans.abort(iw) seems to check out the iw index which is the one immediately after the push conflict, though the stack is unmodified, i.e. stg status shows some missing files (which are added by subsequent patches after the conflicting one) and a conflict. What I would need is a way to save the original iw and and run trans.abort(iw_original). Or simply give up on the --conflict option and always stop after the conflict (catch the exception and don't re-raise it). This way we don't have to bother with checking out the initial state. With the "undo" command in your branch, people could simply revert the stack to the state prior to the sink command. Maybe that's a good idea so that we don't complicate commands further with different conflict behaviours. -- 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
