Re: [PATCH] refs.c: move reflog updates into its own function

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Anything holding this back?

On Thu, Nov 20, 2014 at 4:38 PM, Stefan Beller <sbeller@xxxxxxxxxx> wrote:
> From: Ronnie Sahlberg <sahlberg@xxxxxxxxxx>
>
> write_ref_sha1 tries to update the reflog while updating the ref.
> Move these reflog changes out into its own function so that we can do the
> same thing if we write a sha1 ref differently, for example by writing a ref
> to the packed refs file instead.
>
> No functional changes intended. We only move some code out into a separate
> function.
>
> Signed-off-by: Ronnie Sahlberg <sahlberg@xxxxxxxxxx>
> Signed-off-by: Stefan Beller <sbeller@xxxxxxxxxx>
> ---
>
>  Examining the refs-transaction-reflog series a bit closer, this seems to be
>  one of the last independant patches, which make sense to rip out on a per-patch
>  basis.
>
>
>  refs.c | 60 +++++++++++++++++++++++++++++++++++-------------------------
>  1 file changed, 35 insertions(+), 25 deletions(-)
>
> diff --git a/refs.c b/refs.c
> index 005eb18..6837367 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -3043,6 +3043,40 @@ int is_branch(const char *refname)
>         return !strcmp(refname, "HEAD") || starts_with(refname, "refs/heads/");
>  }
>
> +static int write_sha1_update_reflog(struct ref_lock *lock,
> +       const unsigned char *sha1, const char *logmsg)
> +{
> +       if (log_ref_write(lock->ref_name, lock->old_sha1, sha1, logmsg) < 0 ||
> +           (strcmp(lock->ref_name, lock->orig_ref_name) &&
> +            log_ref_write(lock->orig_ref_name, lock->old_sha1, sha1, logmsg) < 0)) {
> +               unlock_ref(lock);
> +               return -1;
> +       }
> +       if (strcmp(lock->orig_ref_name, "HEAD") != 0) {
> +               /*
> +                * Special hack: If a branch is updated directly and HEAD
> +                * points to it (may happen on the remote side of a push
> +                * for example) then logically the HEAD reflog should be
> +                * updated too.
> +                * A generic solution implies reverse symref information,
> +                * but finding all symrefs pointing to the given branch
> +                * would be rather costly for this rare event (the direct
> +                * update of a branch) to be worth it.  So let's cheat and
> +                * check with HEAD only which should cover 99% of all usage
> +                * scenarios (even 100% of the default ones).
> +                */
> +               unsigned char head_sha1[20];
> +               int head_flag;
> +               const char *head_ref;
> +               head_ref = resolve_ref_unsafe("HEAD", RESOLVE_REF_READING,
> +                                             head_sha1, &head_flag);
> +               if (head_ref && (head_flag & REF_ISSYMREF) &&
> +                   !strcmp(head_ref, lock->ref_name))
> +                       log_ref_write("HEAD", lock->old_sha1, sha1, logmsg);
> +       }
> +       return 0;
> +}
> +
>  /*
>   * Write sha1 into the ref specified by the lock. Make sure that errno
>   * is sane on error.
> @@ -3086,34 +3120,10 @@ static int write_ref_sha1(struct ref_lock *lock,
>                 return -1;
>         }
>         clear_loose_ref_cache(&ref_cache);
> -       if (log_ref_write(lock->ref_name, lock->old_sha1, sha1, logmsg) < 0 ||
> -           (strcmp(lock->ref_name, lock->orig_ref_name) &&
> -            log_ref_write(lock->orig_ref_name, lock->old_sha1, sha1, logmsg) < 0)) {
> +       if (write_sha1_update_reflog(lock, sha1, logmsg)) {
>                 unlock_ref(lock);
>                 return -1;
>         }
> -       if (strcmp(lock->orig_ref_name, "HEAD") != 0) {
> -               /*
> -                * Special hack: If a branch is updated directly and HEAD
> -                * points to it (may happen on the remote side of a push
> -                * for example) then logically the HEAD reflog should be
> -                * updated too.
> -                * A generic solution implies reverse symref information,
> -                * but finding all symrefs pointing to the given branch
> -                * would be rather costly for this rare event (the direct
> -                * update of a branch) to be worth it.  So let's cheat and
> -                * check with HEAD only which should cover 99% of all usage
> -                * scenarios (even 100% of the default ones).
> -                */
> -               unsigned char head_sha1[20];
> -               int head_flag;
> -               const char *head_ref;
> -               head_ref = resolve_ref_unsafe("HEAD", RESOLVE_REF_READING,
> -                                             head_sha1, &head_flag);
> -               if (head_ref && (head_flag & REF_ISSYMREF) &&
> -                   !strcmp(head_ref, lock->ref_name))
> -                       log_ref_write("HEAD", lock->old_sha1, sha1, logmsg);
> -       }
>         if (commit_ref(lock)) {
>                 error("Couldn't set %s", lock->ref_name);
>                 unlock_ref(lock);
> --
> 2.2.0.rc2.23.gca0107e
>
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]