From: Josh Triplett <josh@joshtriplett.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jamey Sharp <jamey@minilop.net>,
"Shawn O. Pearce" <spearce@spearce.org>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Jeff King <peff@peff.net>, Jakub Narebski <jnareb@gmail.com>,
Bert Wesarg <bert.wesarg@googlemail.com>,
git@vger.kernel.org
Subject: Re: [PATCH] ref namespaces: tests
Date: Thu, 14 Jul 2011 20:45:39 -0700 [thread overview]
Message-ID: <20110715034538.GD28343@leaf> (raw)
In-Reply-To: <7v1uxs3177.fsf@alter.siamese.dyndns.org>
On Thu, Jul 14, 2011 at 04:13:48PM -0700, Junio C Hamano wrote:
> Josh Triplett <josh@joshtriplett.org> writes:
> > create mode 100755 t/t5502-fetch-push-namespaces.sh
>
> Isn't 5502 used already?
Argh. Yes; I put it right after t5501-fetch-push-alternates.sh without
noticing that 5502 already existed. I'll fix it to use t5507. Thanks
for catching that.
> > +test_expect_success setup '
> > + test_tick &&
> > + git init original &&
> > + (
> > + cd original &&
> > + i=0 &&
> > + while [ "$i" -lt 2 ]
> > + do
> > + echo "$i" > count &&
>
> This is just style, but the test scripts prefer to spell these like this:
>
> while test "$i" -lt 2
> do
> echo "$i" >count &&
> ...
>
> to favor "test" over "[ ... ]", and omit SP between ">" redirection (or
> "<" for that matter) and the filename.
Will do. I had done a quick grep-survey of the tests to check usage of
test versus [, and saw enough of both to assume it didn't matter, but it
hadn't occurred to me to check CodingGuidelines for shell scripts; I now
see that it has a section specifically on shell scripting. I'll fix
this in the next version.
Actually, I plan to unroll this two-iteration loop in the next version,
so that I can capture the two object hashes I need for use later in the
script.
Out of curiosity, what's the rationale for the use of test rather than
'['? Just uniformity, or does test have some particular advantage over
'['?
> > + git remote add pushee-namespaced "ext::git --namespace=namespace %s ../pushee" &&
>
> Nice ;-).
Thanks. :)
> > +test_expect_success 'pushing into a repository using a ref namespace' '
> > + (
> > + cd original &&
> > + git push pushee-namespaced master &&
> > + git ls-remote pushee-namespaced > actual &&
> > + printf "dc65a2e0f299dcc7efddbbe01641a28ee84329ba\trefs/heads/master\n" > expected &&
>
> Could you avoid hardcoding the exact object names here? Your script knows
> what object should appear at refs/heads/master at "pushee-namespaced" (as
> you have pushed from the repository "original" you are in), so it may be
> something like:
>
> printf "%s\trefs/heads/mater\n" $(git rev-parse master) >expect
>
> Same comment applies for all the other hardcoded object names.
I can do that; since the same two object hashes recur throughout the
script, I'll record them in shell variables up at the top.
> > +test_expect_success 'mirroring a repository using a ref namespace' '
> > + git clone --mirror pushee mirror &&
> > + (
> > + cd mirror &&
> > + git for-each-ref refs/ > actual &&
> > + printf "dc65a2e0f299dcc7efddbbe01641a28ee84329ba commit\trefs/namespaces/namespace/refs/heads/master\n" > expected &&
> > + printf "fbdf4310c71b916568f04753f603fb24a0544227 commit\trefs/namespaces/namespace/refs/tags/0\n" >> expected &&
> > + printf "dc65a2e0f299dcc7efddbbe01641a28ee84329ba commit\trefs/namespaces/namespace/refs/tags/1\n" >> expected &&
> > + test_cmp expected actual
> > + )
> > +'
>
> I am not sure what you are trying to test. "pushee" is pretending to be a
> hosting site that uses the namespace feature to house refs pushed from
> original in refs/namespaces/namespace/ so it is expected to have these
> refs under there. You didn't make any "git remote" configuration in
> either mirror nor pushee, so it is natural with or without the namespace
> feature that "git clone --mirror" would find them at the same place.
>
> What hasn't been tested in the above is to see what actual refs pushee has
> with (cd pushee && git for-each-ref), and you could argue that this test
> is a proxy for that, but then you are assuming that "clone --mirror" is
> not broken, which means it would make debugging harder when this test does
> start failing---is it the basic namespace feature, or is it mirror cloning
> that acquired a bug to break this test?
I wrote this test specifically to check for possible regressions in
clone or the machinery underneath it. I wanted to ensure that no future
change caused clone to ignore refs in refs/namespaces/*. In particular,
I want to protect against a regression caused by any future change to
the refs machinery that might cause it to ignore refs outside of
refs/heads/* or refs/tags/*, which might otherwise go un-noticed (as
they almost did during the development of this patchset, if not for an
incidental side effect of t5501).
If this test failed, I would expect that it would fail because clone
--mirror produced a mirrored repository which didn't actually contain
any refs, even though pushee contained the correctly namespaced refs;
thus, for-each-ref doesn't seem like the right test.
More generally, I also added this test because it tests a specific
high-level feature I care about: the ability to mirror a repository
containing namespaces using clone --mirror, and preserve those
namespaces. I plan to use that as a backup mechanism, and I want it to
continue working. :)
- Josh Triplett
next prev parent reply other threads:[~2011-07-15 3:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-14 20:50 [PATCH] ref namespaces: tests Josh Triplett
2011-07-14 23:13 ` Junio C Hamano
2011-07-15 3:45 ` Josh Triplett [this message]
2011-07-15 18:40 ` [PATCHv2] " Josh Triplett
2011-07-21 20:10 ` [PATCHv3] " Josh Triplett
2011-07-21 21:56 ` Junio C Hamano
2011-07-22 22:32 ` Jeff King
2011-07-15 19:37 ` [PATCH] " 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=20110715034538.GD28343@leaf \
--to=josh@joshtriplett.org \
--cc=Johannes.Schindelin@gmx.de \
--cc=bert.wesarg@googlemail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jamey@minilop.net \
--cc=jnareb@gmail.com \
--cc=peff@peff.net \
--cc=spearce@spearce.org \
/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).