git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).