On 2008-09-18 12:31:35 +0100, Catalin Marinas wrote:
> 2008/9/18 Karl Hasselström <kha@xxxxxxxxxxx>:
>
> > 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.
Hmm, strange. That's not what I thought it was supposed to do. Look at
how coalesce uses it, for example.
> 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.
Yes, this is what every other command does, so it makes sense
consistency-wise.
But I liked the idea of your "roll-back-in-case-of-conflicts" flag; it
would be nice to have in many commands.
--
Karl Hasselström, kha@xxxxxxxxxxx
www.treskal.com/kalle
--
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
