Re: [PATCH 1/2] update-ref: Allow creation of multiple transactions
- From
Patrick Steinhardt <ps@pks.im>
- Date
- Nov 6, 2020, 06:36 UTC
- Message-ID
- <20201106063653.GA3692@ncase>
- In-Reply-To
- <20201105192901.GA121650@coredump.intra.peff.net>
On Thu, Nov 05, 2020 at 02:29:01PM -0500, Jeff King wrote:
Show 41 quoted lines
> On Wed, Nov 04, 2020 at 03:57:17PM +0100, Patrick Steinhardt wrote: > > > While git-update-ref has recently grown commands which allow interactive > > control of transactions in e48cf33b61 (update-ref: implement interactive > > transaction handling, 2020-04-02), it is not yet possible to create > > multiple transactions in a single session. To do so, one currently still > > needs to invoke the executable multiple times. > > > > This commit addresses this shortcoming by allowing the "start" command > > to create a new transaction if the current transaction has already been > > either committed or aborted. > > Thanks for working on this. The amount of change needed is indeed quite > pleasant. > > > diff --git a/Documentation/git-update-ref.txt b/Documentation/git-update-ref.txt > > index d401234b03..48b6683071 100644 > > --- a/Documentation/git-update-ref.txt > > +++ b/Documentation/git-update-ref.txt > > @@ -125,7 +125,8 @@ option:: > > start:: > > Start a transaction. In contrast to a non-transactional session, a > > transaction will automatically abort if the session ends without an > > - explicit commit. > > + explicit commit. This command may create a new empty transaction when > > + the current one has been committed or aborted already. > > Reading this made me wonder what would happen if we send a "start" when > the current one _hasn't_ been committed or aborted. I.e., what does: > > git update-ref --stdin <<EOF > start > create refs/heads/foo ... > start > commit > EOF > > do? It turns out that the second start is ignored totally (and the > commit does indeed update foo). I wonder if we ought to complain about > it. But that is completely orthogonal to your patch. The behavior is the > same before and after.
Agreed, that's a case where we should raise an error. Doing nothing without any indication is a bad way of handling it.
Patrick