On Mon, May 5, 2014 at 4:22 AM, Michael Haggerty <mhag...@alum.mit.edu> wrote:
> On 04/22/2014 08:45 PM, Ronnie Sahlberg wrote:
>> This change is based on the previous ref transaction patches.
>> This is sent as a separate patch series since it implements a lot more
>> non-trivial changes to the behaviour than the previous patches and thus can
>> use more detailed review.
>> Update fetch.c to use ref transactions when performing updates. Use a single
>> ref transaction for all updates and only commit the transaction if all other
>> checks and oeprations have been successful. This makes the ref updates during
>> a fetch (mostly) atomic.
> Is this always an improvement?  What kind of checks are there that might
> fail?
> It would be pretty annoying to spend a lot of time fetching a big pack,
> only to have the fetch fail because one reference out of many couldn't
> be updated.  This would force the user to download the entire pack
> again, whereas if the successful reference updates had been allowed,
> then probably most or all of the second download would have been avoidable.
> On the other hand, if a reference was renamed on the remote side,
> allowing a partial reference update could cause history to be discarded
> locally if the old name's delete was accepted but the new name's
> addition was rejected.  This wouldn't be the end of the world, because
> the history is presumably still available remotely to fetch again, but
> it's not ideal either.
> I'm not sure myself what I would prefer, but I wanted to point out that
> it is IMO not obvious that atomicity here is an improvement.

We could make it a .git/config option ?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to