Git development
 help / color / mirror / Atom feed
From: Clemens Buchacher <drizzd@aon.at>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH] push: fix local refs update if already up-to-date
Date: Wed, 5 Nov 2008 21:28:49 +0100	[thread overview]
Message-ID: <20081105202849.GA9484@localhost> (raw)
In-Reply-To: <20081105024932.GA20907@coredump.intra.peff.net>

On Tue, Nov 04, 2008 at 09:49:32PM -0500, Jeff King wrote:
[...]
> However, I would like to make one additional request.  Since you are
> killing off all usage of new_sha1 initial assignment, I think it makes
> sense to just get rid of the variable entirely, so it cannot create
> confusion later.

Ok, I can live with that.

> > > Hmm. I was hoping to see more in update_tracking_ref. With your patch,
> > > we end up calling update_ref for _every_ uptodate ref, which results in
> > > writing a new unpacked ref file for each one. And that _is_ a
> > > performance problem for people with large numbers of refs.
> > [...]
> > I think update_ref already takes care of that. See this check in
> > write_ref_sha1:
> > 
> >         if (!lock->force_write && !hashcmp(lock->old_sha1, sha1)) {
> >                 unlock_ref(lock);
> >                 return 0;
> >         }
> 
> Nope. That check is a concurrency safeguard. It checks that when we are
> moving the ref from "A" to "B", that the ref still _is_ "A" when we lock
> it.

I think you are confusing this with verify_lock(). The code in
write_ref_sha1() really does compare with the new sha1.

> But more importantly, it is easy to demonstrate the problem with your
> patch:
> 
>   mkdir parent &&
>     (cd parent &&
>        git init && touch file && git add file && git commit -m one) &&
>   git clone parent child &&
>     (cd child &&
>        echo BEFORE: && ls -l .git/refs/remotes/origin &&
>        git push &&
>        echo AFTER:  && ls -l .git/refs/remotes/origin)
> 
> I get:
> 
>   BEFORE:
>   -rw-r--r-- 1 peff peff 32 2008-11-04 21:43 HEAD
>   Everything up-to-date
>   AFTER:
>   -rw-r--r-- 1 peff peff 32 2008-11-04 21:43 HEAD
>   -rw-r--r-- 1 peff peff 41 2008-11-04 21:43 master
> 
> Oops. With the patch snippet I posted in my previous message, the
> 'master' ref is not created by the uptodate push.

The reason it doesn't work is a bug in lock_ref_sha1_basic(). Dating back to
pre-"pack-refs" times, this code forces a write if the ref file does not
exist. I will resubmit the patch including your above testcase and a bugfix
for lock_ref_sha1_basic().

Clemens

  reply	other threads:[~2008-11-05 20:30 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-04  0:07 [PATCH] push: fix local refs update if already up-to-date Clemens Buchacher
2008-11-04  4:26 ` Jeff King
2008-11-04  8:38   ` Junio C Hamano
2008-11-04  9:05     ` Clemens Buchacher
2008-11-04  8:56   ` Clemens Buchacher
2008-11-05  2:49     ` Jeff King
2008-11-05 20:28       ` Clemens Buchacher [this message]
2008-11-05 20:55         ` [PATCH 1/2] do not force write of packed refs Clemens Buchacher
2008-11-05 20:55           ` [PATCH 2/2] push: fix local refs update if already up-to-date Clemens Buchacher
2008-11-05 21:57         ` [PATCH] " Clemens Buchacher
2008-11-05 22:23           ` Junio C Hamano
2008-11-05 22:44         ` Jeff King
2008-11-04 20:57   ` [PATCH v2] " Clemens Buchacher
2008-11-05  2:51     ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081105202849.GA9484@localhost \
    --to=drizzd@aon.at \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox