Re: [PATCH v2 18/27] update-ref --stdin: Harmonize error messages

[Junio C Hamano <gitster@pobox.com>]

Michael Haggerty <mhagger@alum.mit.edu> writes:

> Junio, I incorporated your feedback (which so far has only affected
> commit messages).  I also rebased the patch series to the current
> master.  I pushed the result to GitHub [1].  I'll refrain from spamming
> the list with v3 yet.

Thanks; let us know when you are ready ;-) I finished reading the
remainder of the v2, and I think I sent out what I found worth
commenting on (either positive or negative).

I think the next thing to convert to the transaction API would be
the "ok we know the set of updates from the pusher; let's update all
of them" in receive-pack?  In a sense that is of a lot more
real-world impact than the update-ref plumbing.  

           Side note: honestly speaking, I was dissapointed to see
           that the ref updates by the receive-pack process was not
           included in the series when I saw the cover letter that
           said this was a series about transactional updates to
           refs.  Anyway...

There are a few things that need to be thought through.

Making the update in receive-pack all-or-none is a behaviour change,
even though it may be a good one.  We may want to allow the user a
way to ask for the traditional "reject only the ones that cannot be
updated".  It probably goes like this:

 - On the wire, a new "ref-update-aon" capability is
   advertised from receive-pack to send-pack and can be requested in
   the opposite direction.

 - On the "git push" side, a new "--all-or-none" option, and
   optionally a new "push.allOrNone" configuration, is used to
   request the "ref-update-aon" capability over the wire.

 - On the receive-pack side, a new "receive.allOrNone" configuration 
   can be used to always update refs in all-or-none fashion, no
   matter what the pusher says.

 - The receive-pack uses the ref transaction to update the refs in
   all-or-none fashion if it has receive.allOrNone, or both sides
   agree to use ref-update-aon in the capability exchange.  If not,
   it updates the refs in some-may-succeed-some-may-fail fashion,
   one by one.

Or something like that.