Re: [PATCH v3 12/19] initial_ref_transaction_commit(): check for duplicate refs

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 22, 2015, 21:06 UTC
Message-ID: <xmqqtwtzfo79.fsf@gitster.dls.corp.google.com>
In-Reply-To: <63ae59139a3a7b5c85f6d44864eade79a93965fb.1434980615.git.mhagger@alum.mit.edu>

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

Show 7 quoted lines

> Error out if the ref_transaction includes more than one update for any
> refname.
>
> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
> ---
>  refs.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)

This somehow feels like "ehh, I now know better and this function should have been like this from the beginning" to me.

But that is OK.

Is the initial creation logic too fragile to deserve its own function to force callers to think about it, by the way?

What I am wondering is if we could turn the safety logic that appear here (i.e. no existing refs must be assumed by the set of updates, etc.) into an optimization cue and implement this as a special case helper to ref_transaction_commit(), i.e.

	ref_transaction_commit(...)
        {
		if (updates are all initial creation &&
                    no existing refs in repository)
			return initial_ref_transaction_commit(...);
		/* otherwise we do the usual thing */
		...
	}

and have "clone" call ref_transaction_commit() as usual.