List for cgit developers and users
 help / color / mirror / Atom feed
From: mailings at hupie.com (Ferry Huberts)
Subject: [PATCH] tests: use Git's test framework
Date: Thu, 04 Apr 2013 18:19:38 +0200	[thread overview]
Message-ID: <515DA81A.7070909@hupie.com> (raw)
In-Reply-To: <CAHmME9qJh2=QCnq+GWRCOPK6JqWMqATQS6AVcHfYuAn5=0bqEA@mail.gmail.com>



On 04/04/13 16:32, Jason A. Donenfeld wrote:
> On Mon, Apr 1, 2013 at 4:09 PM, John Keeping <john at keeping.me.uk> wrote:
>> Obviously there are a number of further changes that can be done on top
>> of this to avoid the now-unnecessary wrapper functions and use a test
>> prerequisite for HTML tidy but I don't want to work on those unless
>> there is agreement that this is a sensible direction.
> 
> If moving forward with this would indeed result in reducing the
> complexity of our own test harness, I'm okay with that. Removing our
> wrapper would be quite nice. AFAIK, git's testing infrastructure is
> fairly stable, so I don't anticipate using it will introduce any
> unforeseen hiccups down the road.
> 
> Maybe, though, we ought to be having a larger discussion about this.
> We're in the process of bringing cgit up to speed with git head. We're
> now relying on git's Makefile. And now we're discussing using git's
> test infrastructure as well. We're getting cozier with git.
> 
> Is this something we want to do? Or should we say, "let's just be
> friends", before a child is on the way, and then a fight followed by a
> nasty divorce?
> 
> My feeling is that reusing as much of git's existing infrastructure is
> ideal and should be encouraged. One of the strengths of cgit has
> always been that we use the actual meat of git and are tied to it in
> an intimate way. In fact, down the road, if cgit is in a ripe position
> for merging in some respect with git-itself, I think this is also
> something I'd be in favor of. (But hey, it's only the third date;
> let's not get too excited about such futures ;-).
> 

I'm completely in favor of doing this, it will make upstreaming cgit
into git way easier once cgit is in a good enough position

> So from this perspective, I'd be in support of relying on git's test harness.
> 
> But there might be other considerations I've overlooked; my ears are
> open to dissenting opinions.
> 
> _______________________________________________
> cgit mailing list
> cgit at hjemli.net
> http://hjemli.net/mailman/listinfo/cgit
> 

-- 
Ferry Huberts




  reply	other threads:[~2013-04-04 16:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-01 14:09 john
2013-04-04 14:24 ` Jason
2013-04-04 14:34   ` john
2013-04-04 14:32 ` Jason
2013-04-04 16:19   ` mailings [this message]
2013-04-07 15:28 ` Jason
2013-04-08 14:28   ` Jason

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=515DA81A.7070909@hupie.com \
    --to=cgit@lists.zx2c4.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).