On Mon, Feb 9, 2015 at 1:12 AM, Michael Haggerty <mhag...@alum.mit.edu> wrote:
> When processing the reflog of a symbolic ref, hold the lock on the
> symbolic reference itself, not on the reference that it points to.
I am not sure if that makes sense.
So when expiring HEAD, you want to have a .git/HEAD.lock file
instead of a .git/refs/heads/master.lock file?
What would happen if there is a concurrent modification
to the master branch?
>
> Signed-off-by: Michael Haggerty <mhag...@alum.mit.edu>
> ---
> refs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/refs.c b/refs.c
> index 1b2a497..3fcf342 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -4037,7 +4037,7 @@ int reflog_expire(const char *refname, const unsigned
> char *sha1,
> * reference itself, plus we might need to update the
> * reference if --updateref was specified:
> */
> - lock = lock_ref_sha1_basic(refname, sha1, NULL, 0, &type);
> + lock = lock_ref_sha1_basic(refname, sha1, NULL, REF_NODEREF, &type);
> if (!lock)
> return error("cannot lock ref '%s'", refname);
> if (!reflog_exists(refname)) {
> --
> 2.1.4
>
--
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
