Michael Haggerty <mhagger@xxxxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html