Re: [RFC PATCH] Record a single transaction for conflicting push operations

On Mon, Dec 21, 2009 at 12:48 PM, Catalin Marinas
[off-list ref] wrote:

2009/12/21 Karl Wiberg [off-list ref]:

quoted

By the way, you do realize there's another command that requires
two steps to undo completely: refresh? And that one is harder to
get out of---undoing it all in one step would mean throwing away
the updates to the patch.

But it looks to me like refresh does this by running separate
transactions.

Yes. So it won't be affected by whatever you do here. (Unless you
consider that refresh -p needs to reorder patches, which can result in
conflicts---right now, refresh -p can result in three log entries.)

The push command does this in a single transaction, so the quickest
fix for the HEAD != top undo problem was to only record one log per
transaction.

I've seen more than one complaint that the current behavior is
confusing even if we don't count the bug, so I thought this was part
of the motivation.

If we keep the current behaviour with two logs per transaction, we
need to preserve the HEAD prior to the conflict so that logging
doesn't get the wrong HEAD (which is the new conflicting HEAD
currently). The patch below appears to fix this problem and still
generate two logs per transaction. While I'm more in favour of a
single log per transaction, if people find it useful I'm happy to
keep the current behaviour.

I haven't seen anyone but me defent the current design, and it's not a
big deal for me either, so I'd say go with just one transaction.

-- 
Karl Wiberg, kha@treskal.com
   subrabbit.wordpress.com
   www.treskal.com/kalle