From: Junio C Hamano <gitster@pobox.com>
Date: Fri, 26 Sep 2014 19:00:06 GMT
Subject: Re: [PATCH v6 27/39] try_merge_strategy(): use a statically-allocated lock_file object
Message-ID: <xmqqh9zu8ax5.fsf@gitster.dls.corp.google.com>
In-Reply-To: <1411726119-31598-28-git-send-email-mhagger@alum.mit.edu>

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

> Even the one lockfile object needn't be allocated each time the
> function is called.  Instead, define one statically-allocated
> lock_file object and reuse it for every call.
>
> Suggested-by: Jeff King <peff@peff.net>
> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
> ---
> ...
> -	hold_locked_index(lock, 1);
> +	hold_locked_index(&lock, 1);
>  	refresh_cache(REFRESH_QUIET);
>  	if (active_cache_changed &&
> -	    write_locked_index(&the_index, lock, COMMIT_LOCK))
> +	    write_locked_index(&the_index, &lock, COMMIT_LOCK))

I wondered if the next step would be to lose the "lock" parameter
from {hold,write}_locked_index() and have them work on a
process-global lock, but that would not work well.

The reason why this patch works is because we are only working with
a single destination (i.e. $GIT_INDEX_FILE typically .git/index),
right?

Interesting.