From: Jeff King <peff@peff.net>
To: mhagger@alum.mit.edu
Cc: Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org, Jakub Narebski <jnareb@gmail.com>,
Heiko Voigt <hvoigt@hvoigt.net>,
Johan Herland <johan@herland.net>
Subject: Re: [PATCH 0/4] Remove a user of extra_refs in clone
Date: Tue, 17 Jan 2012 01:35:11 -0500 [thread overview]
Message-ID: <20120117063511.GA27770@sigill.intra.peff.net> (raw)
In-Reply-To: <1326779434-20106-1-git-send-email-mhagger@alum.mit.edu>
On Tue, Jan 17, 2012 at 06:50:30AM +0100, mhagger@alum.mit.edu wrote:
> When cloning, write_remote_refs() creates local packed refs from the
> refs read from the remote repository. It does this by creating extra
> refs for the references then calling pack_refs() to bake the extra
> refs into the packed-refs file, then calling clear_extra_refs().
>
> This is silly and relies on the kludgy extra_refs mechanism, which I
> want to get rid of. Instead, add a function call add_packed_ref() to
> the refs API, and use it to create packed refs (in the memory cache)
> directly. Then call pack_refs() as before to write the packed-refs
> file.
I certainly approve of the goal.
> Because the new add_packed_ref() function allows references (perhaps
> many of them) to be added to an existing ref_array, it would be
> inefficient to re-sort the list after every addition. So instead,
> append new entries to the end of the ref_array and note that the array
> is unsorted. Then, before the ref_array is used, check if it is
> unsorted and sort it if necessary.
Makes sense.
> A side effect of this change is that the new packed references are
> left in the in-memory packed reference cache after the return from
> write_remote_refs() (whereas previously, the refs were stored as
> temporary extra refs that were purged before return from the
> function). I can't see any place in the following code where this
> would make a difference, but there is quite a bit of code there so it
> is hard to audit. Confirmation that this is OK would be welcome.
Actually, I think you may be fixing an extremely minor bug with this.
If later code in clone tries to resolve one of the refs in
refs/remotes/<origin>/, the current code will see that it doesn't exist
as a ref file (because we wrote it packed) and call get_packed_ref. That
checks the cached refs list, which will claim that did_packed is true,
but the "packed" array will be empty. Which is wrong; we _do_ have that
ref, and our cache is stale. After writing the packed list, the current
code probably ought to be calling invalidate_ref_cache(). It was only
the fact that most of the remaining code didn't care that this wasn't a
bug in the first place.
Your code makes more sense, in that it will keep the packed_refs list up
to date, and later calls to resolve_ref will properly find those refs.
The only place where I can detect a change in behavior is in the reflog
creation. When we write the refs/remotes/<origin>/HEAD ref, we call
create_symref, which in turn will decide whether to write a reflog entry
or not based on whether the pointed-to ref exists (because if we are
making a symref to something that doesn't exist, we have no sha1 to
write in the reflog entry). So before, we got no reflog for
refs/remotes/<origin>/HEAD (because we erroneously thought that
refs/remotes/origin/master (or whatever) did not exist). With your
patches, the reflog entry is created.
I doubt anyone ever noticed, but now that code is at least working as
intended.
> Michael Haggerty (4):
> pack_refs(): remove redundant check
> ref_array: keep track of whether references are sorted
> add_packed_ref(): new function in the refs API.
> write_remote_refs(): create packed (rather than extra) refs
I won't respond to each patch individually. All of them looked good to
me. Thanks for a very pleasant read.
-Peff
next prev parent reply other threads:[~2012-01-17 6:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-17 5:50 [PATCH 0/4] Remove a user of extra_refs in clone mhagger
2012-01-17 5:50 ` [PATCH 1/4] pack_refs(): remove redundant check mhagger
2012-01-17 5:50 ` [PATCH 2/4] ref_array: keep track of whether references are sorted mhagger
2012-01-17 5:50 ` [PATCH 3/4] add_packed_ref(): new function in the refs API mhagger
2012-01-17 5:50 ` [PATCH 4/4] write_remote_refs(): create packed (rather than extra) refs mhagger
2012-01-17 6:35 ` Jeff King [this message]
2012-01-17 6:51 ` [PATCH 0/4] Remove a user of extra_refs in clone Junio C Hamano
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=20120117063511.GA27770@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=hvoigt@hvoigt.net \
--cc=jnareb@gmail.com \
--cc=johan@herland.net \
--cc=mhagger@alum.mit.edu \
/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;
as well as URLs for NNTP newsgroup(s).