From: Eric Gerlach <egerlach@feds.uwaterloo.ca>
To: Jeff King <peff@peff.net>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: Is "show-ref -h" a good test for an empty repository?
Date: Mon, 08 Sep 2008 09:24:39 -0400 [thread overview]
Message-ID: <48C52797.3030500@feds.uwaterloo.ca> (raw)
In-Reply-To: <20080907173434.GA26182@coredump.intra.peff.net>
Jeff King wrote:
> On Sun, Sep 07, 2008 at 10:31:52AM -0700, Junio C Hamano wrote:
>
>> All depends on how "an empty repository" is defined. My definition of an
>> empty repository would have been:
>>
>> - No objects in it;
>> - No index;
>> - No refs except symrefs.
>
> Agreed. In the original message, he used the phrase "no existing
> commits" which I latched onto (to mean "no existing commits on this
> branch"). But the subject does say "empty repository". :)
>
> Eric, maybe you can tell us more about what you're trying to accomplish?
Sure, I'm writing a patch for the debcommit script for the Debian
project. It's a script which parses the Debian changelog for a package,
generates a commit message, and commits to an SCM system.
The case I'm looking to protect against is the following:
$ mkdir -p new-repo/debian
$ cd new-repo
$ git init
$ vi debian/changelog (add a few lines)
$ git add debian/changelog
$ debcommit
(which runs
$ git diff --cached debian/changelog)
If I can test before the git-diff, then I can run "diff debian/changelog
/dev/null" instead of the git-diff and all is well.
I don't want to test failure of the git-diff itself, because I want
debcommit to fail if there's something wrong *other* than a new repo.
Also, I want to use a git command to do it, because I don't have any
guarantees about how things are setup, other than "we're using git."
I'm okay with debcommit proceeding if the repo has a commit but is
borked from manually editing the HEAD ref, but I'm not sure how the
maintainers of the script feel about that. So if it's possible to
differentiate between the two cases, bonus, but not necessary.
So that's where I'm sitting. Jeff and Junio, thanks for the help and
discussion. This is great :-)
(BTW, I'm leaning to the rev-parse right now; looking at the source it
seems to be more precise, i.e. has fewer ways to fail)
Cheers,
Eric
next prev parent reply other threads:[~2008-09-08 13:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-06 0:45 Is "show-ref -h" a good test for an empty repository? Eric Gerlach
2008-09-06 1:29 ` Jeff King
2008-09-07 14:21 ` Eric Gerlach
2008-09-07 15:50 ` Jeff King
2008-09-07 17:31 ` Junio C Hamano
2008-09-07 17:34 ` Jeff King
2008-09-08 13:24 ` Eric Gerlach [this message]
2008-09-08 14:42 ` 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=48C52797.3030500@feds.uwaterloo.ca \
--to=egerlach@feds.uwaterloo.ca \
--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;
as well as URLs for NNTP newsgroup(s).