user/dev discussion of public-inbox itself
 help / color / Atom feed
From: Stefan Beller <>
To: Eric Wong <>
Cc:, Heiko Voigt <>
Subject: Re: messages dropped in the public inbox ?
Date: Wed, 24 Aug 2016 12:39:26 -0700
Message-ID: <> (raw)
In-Reply-To: <20160824182613.GA8578@whir>

On Wed, Aug 24, 2016 at 11:26 AM, Eric Wong <> wrote:
> Stefan Beller <> wrote:
>> Please see
>> and its answers:
>> Thread overview: 4+ messages in thread (expand / mbox.gz / Atom feed / [top])
>> 2016-08-17 20:48 Stefan Beller [this message]
>> 2016-08-17 21:05 ` Junio C Hamano
>> 2016-08-17 21:14   ` Stefan Beller
>>      [not found]     ` <20160818140922.GA5925@sandbox>
>> 2016-08-24 16:46       ` Stefan Beller
>> The message id 20160818140922.GA5925@sandbox
>> is not found?
>> When I query the git repository for that message
>> (via a generic `git log --author=Heiko --oneline`) I cannot spot
>> the message.
>> Was it just dropped spuriously?
> +Cc: Heiko
> I guess it was dropped by vger, first.
> If you check
> and follow the links to or,
> it's missing in those places, too.

That makes sense. As I was cc'd or adressed directly as well, I did not notice
it's missing on the mailing list as I got it directly.

I just found out about it when I wanted to reference it somewhere else.

> Same with nntp://
> (should load in w3m or lynx)
> It might've also coincided with vger downtime, so perhaps
> Heiko's server failed to retry.  vger has had quite a few
> failures, recently (or perhaps I'm only paying attention more
> now that I'm mirroring git@vger).

Oh, too bad. Thanks for actually pointing out the failure, i.e.
showing that there is a message that was referenced and not just
silently skipping it!

> Based on his other messages and the Message-ID, it looks like he
> used mutt; so it's unlikely to be a problem with HTML (but
> perhaps it was some taboo attachment, but also unlikely).

I don't think so. Here is what I got:
Received: by with SMTP id s69csp335983ios;
        Thu, 18 Aug 2016 07:09:26 -0700 (PDT)
X-Received: by with SMTP id j127mr2593471wmd.9.1471529365942;
        Thu, 18 Aug 2016 07:09:25 -0700 (PDT)
Return-Path: <>
Received: from (
        by with ESMTPS id 201si2451262wmb.59.2016.
        for <>
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Thu, 18 Aug 2016 07:09:25 -0700 (PDT)
Received-SPF: neutral ( is neither permitted
nor denied by best guess record for domain of
       spf=neutral ( is neither permitted nor
denied by best guess record for domain of
Received: from [] (helo=sandbox) by with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128)
(Exim 4.84) (envelope-from <>) id 1baO0a-00034n-JV;
Thu, 18 Aug 2016 16:09:24 +0200
Date: Thu, 18 Aug 2016 16:09:23 +0200
From: Heiko Voigt <>
To: Stefan Beller <>
Cc: Junio C Hamano <>, ""
<>, Jens Lehmann <>, Fredrik
Gustafsson <>
Subject: Re: [PATCH] push: change submodule default to check
Message-ID: <20160818140922.GA5925@sandbox>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Df-Sender: aHZvaWd0QGh2b2lndC5uZXQ=

On Wed, Aug 17, 2016 at 02:14:11PM -0700, Stefan Beller wrote:
> On Wed, Aug 17, 2016 at 2:05 PM, Junio C Hamano <> wrote:
> > Stefan Beller <> writes:
> >> Flipping the default to check for submodules is safer
> >> than the current default of ignoring submodules while pushing.
> >
> > That part of the assertion, on the other hand, is justifiable.
> ok.

I also think that this is a good reason to flip the default. IMO more
people will be annoyed by not being able to checkout a certain version
if someone forgets to push a submodule then people deliberately pushing
something with a submodule hash that is not on any remote.

At the same time I am wondering whether it makes sense to keep this for
a bigger version change (like 3.0) or so? Since that is were people will
expect such changes. Not sure when 3.0 is planned though.

Cheers Heiko

> Anything interesting from looking at the raw message +headers?

If only I had knowledge what is interesting in headers. ;)

Looking at the above, I don't think there is any outstanding
thing why the mailing list would have rejected this mail?


      reply index

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-24 17:04 Stefan Beller
2016-08-24 18:26 ` Eric Wong
2016-08-24 19:39   ` Stefan Beller [this message]

Reply instructions:

You may reply publically 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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

user/dev discussion of public-inbox itself

Archives are clonable:
	git clone --mirror
	git clone --mirror http://czquwvybam4bgbro.onion/meta
	git clone --mirror http://hjrcffqmbrq6wope.onion/meta
	git clone --mirror http://ou63pmih66umazou.onion/meta

Newsgroups are available over NNTP:

 note: .onion URLs require Tor:

AGPL code for this site: git clone public-inbox