On Thu, Nov 05, 2020 at 02:29:01PM -0500, Jeff King wrote: > 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
Attachment:
signature.asc
Description: PGP signature
