git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: David Turner <dturner@twopensource.com>
Cc: git@vger.kernel.org, "Michael Haggerty" <mhagger@alum.mit.edu>,
	"Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
Subject: [PATCH 0/6] avoid touching ref code in non-repositories
Date: Sat, 5 Mar 2016 17:08:29 -0500	[thread overview]
Message-ID: <20160305220829.GA31316@sigill.intra.peff.net> (raw)

Here's the series I mentioned earlier, to avoid avoid accessing the ref
code if we know we aren't in a repository. For those just joining us,
the end goal is to be able to detect and complain when code tries to
open a ref without having run check_repository_format() or similar. Once
we have pluggable ref backends, doing so would be wrong, since we won't
know which backend we're supposed to be using.

It's already _kind of_ wrong, in the sense that we should not be looking
for file-backend refs if we know we don't have a repository. But nobody
really noticed in practice, because you do not generally have
".git/HEAD" lying around in non-repository directories. So it was a de
facto noop, though you could construct pathological cases where it did
the wrong thing.

The patches are:

  [1/6]: setup: make startup_info available everywhere
  [2/6]: setup: set startup_info->have_repository more reliably
  [3/6]: remote: don't resolve HEAD in non-repository
  [4/6]: mailmap: do not resolve blobs in a non-repository
  [5/6]: grep: turn off gitlink detection for --no-index
  [6/6]: use setup_git_directory() in test-* programs

There's a sort-of "7/6" I used to find these spots:

diff --git a/refs/files-backend.c b/refs/files-backend.c
index 81f68f8..22c1b6d 100644
--- a/refs/files-backend.c
+++ b/refs/files-backend.c
@@ -947,6 +947,8 @@ static struct ref_cache *lookup_ref_cache(const char *submodule)
 {
 	struct ref_cache *refs;
 
+	assert(startup_info->have_repository);
+
 	if (!submodule || !*submodule)
 		return &ref_cache;
 
@@ -1414,6 +1416,8 @@ static const char *resolve_ref_1(const char *refname,
 	int depth = MAXDEPTH;
 	int bad_name = 0;
 
+	assert(startup_info->have_repository);
+
 	if (flags)
 		*flags = 0;
 

Running the test suite with that patch and 1/6 turned up the cases I've
fixed here. But I'm not including it here for a few reasons:

  1. I'm not sure that asserting is the best behavior. It's great for
     finding problems (and that's why I used assert() -- to get a
     coredump for the backtrace), but in practice it might be friendlier
     to turn it into a silent noop ("no, I don't even have a ref
     backend, so your ref definitely does not exist").

  2. In a pluggable ref-backend world, this isn't where we'd put the
     asserts, anyway. We'd do it when accessing the ref_backend vtable
     (or just starting with a dummy vtable that asserts, or returns
     "nope, no refs", or whatever).

So it was useful for debugging/analysis now, and we may want something
like it later, but I think that should come on top the ref-backend
series.

-Peff

             reply	other threads:[~2016-03-05 22:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-05 22:08 Jeff King [this message]
2016-03-05 22:10 ` [PATCH 1/6] setup: make startup_info available everywhere Jeff King
2016-03-05 22:11 ` [PATCH 2/6] setup: set startup_info->have_repository more reliably Jeff King
2016-03-05 22:11 ` [PATCH 3/6] remote: don't resolve HEAD in non-repository Jeff King
2016-03-05 22:13 ` [PATCH 4/6] mailmap: do not resolve blobs in a non-repository Jeff King
2016-03-05 22:15 ` [PATCH 5/6] grep: turn off gitlink detection for --no-index Jeff King
2016-03-07  1:29   ` Junio C Hamano
2016-03-07 15:51     ` [PATCH v2 " Jeff King
2016-03-05 22:16 ` [PATCH 6/6] use setup_git_directory() in test-* programs Jeff King
2016-03-07  1:28   ` 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=20160305220829.GA31316@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=dturner@twopensource.com \
    --cc=git@vger.kernel.org \
    --cc=mhagger@alum.mit.edu \
    --cc=pclouds@gmail.com \
    /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).