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

From: Karl Wiberg <kha@treskal.com>
Date: Dec 21, 2009, 13:48 UTC
Message-ID: <b8197bcb0912210548q67c1da4bhe023bed2811394d4@mail.gmail.com>
In-Reply-To: <b0943d9e0912210348o37b71935x5fad4f1a4be4b70@mail.gmail.com>

On Mon, Dec 21, 2009 at 12:48 PM, Catalin Marinas <catalin.marinas@gmail.com> wrote:

Show 9 quoted lines

> 2009/12/21 Karl Wiberg <kha@treskal.com>:
>
>> 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.

Show 7 quoted lines

> 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