Anything holding this back?
On Thu, Nov 20, 2014 at 4:38 PM, Stefan Beller <sbeller@google.com> wrote:
Show 106 quoted lines
> From: Ronnie Sahlberg <sahlberg@google.com>
>
> 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@google.com>
> Signed-off-by: Stefan Beller <sbeller@google.com>
> ---
>
> 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
>Stefan Beller <sbeller@google.com>