Re: Can't push to haddock

[Manuel M T Chakravarty]

I think, what Sven is getting at here —and I do have to say, I concur— is that 
there is a bit of NIH (Not Invented Here) syndrome in parts of the Haskell 
community. I think, part of it is just inertia and the desire to keep things 
the same, because that is easier and more familiar.

One aspect that complicates this discussion significantly is that GHC dev has 
developed certain work arounds and ways of doing things, where third party 
infrastructure seems lacking in features, because it doesn’t support all these 
quirks. However, it turns out that if we are only prepared to change our 
workflow and processes to align with modern software development practices, 
many of theses ”features” aren’t actually necessary. We have seen quite a bit 
of that in the CI discussion. 

I am not writing this to blame anything or anybody. I think, it is a normal 
part of a healthy process of change. However, it complicates the discussion as 
people get hung up on individual technicalities, such as this or that feature 
is missing, without considering the big picture.

Generally, I think, a worthwhile golden rule in ops is that custom 
infrastructure is bad. It creates extra work, technical debt, and failure 
points. So, IMHO the default ought to be to use 3rd part infrastructure (like 
GitHub) and only augment that where absolutely necessary. This will simply 
leave us with more time to write Haskell code in GHC instead of building, 
maintaining, and supporting GHC infrastructure. 

Cheers,
Manuel

> 19.12.2017 20:47 Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org>:
> 
> It seems to me that there is some hostility towards GitHub in GHC HQ, but I 
> don't really understand why. GitHub serves other similar projects quite well, 
> e.g. Rust, and I can't see why we should be special.
> 
> Speaking for myself, I have no hostility towards GitHub, and there is no 
> GHC-HQ bias against it that I know of.  If it serves the purpose better, we 
> should use it.   Indeed that’s why I asked my original question.  I agree 
> with your point that data may actually be safer in GitHub than in our own 
> repo.   (And there is nothing to stop a belt-and-braces mirror backup system.)
>  
> The issue is: does GitHub serve the purpose better?   We have frequently 
> debated this multi-dimensional question.  And we should continue to do so: 
> the answers may change over time (GitHub’s facilities are not static; and its 
> increasing dominance is itself a cultural familiarity factor that simply was 
> not the case five years ago).
>  
> Simon
>  
> From: Sven Panne [mailto:svenpa...@gmail.com] 
> Sent: 19 December 2017 09:30
> To: Herbert Valerio Riedel <hvrie...@gmail.com>
> Cc: Simon Peyton Jones <simo...@microsoft.com>; ghc-devs@haskell.org Devs 
> <ghc-devs@haskell.org>
> Subject: Re: Can't push to haddock
>  
> 2017-12-19 9:50 GMT+01:00 Herbert Valerio Riedel <hvrie...@gmail.com 
> <mailto:hvrie...@gmail.com>>:
> 
> We'd need mirroring anyway, as we want to keep control over our
> infrastructure and not have to trust a 3rd party infrastructure to
> safely handle our family jewels: GHC's source tree.
> 
>  
> 
> I think this is a question of perspective: Having the master repository on 
> GitHub doesn't mean you are in immediate danger or lose your "family jewels". 
> IMHO it's quite the contrary: I'm e.g. sure that in case that something goes 
> wrong with GitHub, there is far more manpower behind it to fix that than for 
> any self-hosted repository. And you can of course have some mirror of your 
> GitHub repo in case of e.g. an earthquake/meteor/... in the San Francisco 
> area... ;-)
> 
>  
> 
> It seems to me that there is some hostility towards GitHub in GHC HQ, but I 
> don't really understand why. GitHub serves other similar projects quite well, 
> e.g. Rust, and I can't see why we should be special.
> 
>  
> 
> Also, catching bad commits "a bit later" is just asking for trouble --
> by the time they're caught the git repos have already lost their
> invariant and its a big mess to recover;
> 
>  
> 
> This is by no means different than saying: "I want to run 'validate' in the 
> commit hook, otherwise it's a big mess." We don't do this for obvious 
> reasons, and what is the "big mess" if there is some incorrect submodule 
> reference for a short time span? How is that different from somebody 
> introducing e.g. a subtle compiler bug in a commit?
> 
>  
> 
> the invariant I devised and
> whose validation I implemented 4 years ago has served us pretty well,
> and has ensured that we never glitched into incorrectness; I'm also not
> sure why it's being suggested to switch to a less principled and more
> fragile scheme now. [...]
> 
> 

Re: Can't push to haddock

[Manuel M T Chakravarty]

Thank you for that word of reason.

(In addition to your very well stated point, the whole point of Git is that it 
is a *distributed* RCS. I don’t think, anything less than a full scale 
planetary nuclear war could really wipe out the GHC source code at this point.)

Manuel

> 20.12.2017 05:02 Gershom B :
> 
>> You're also assuming github doesn't suddenly pull a SourceForge (or a
>> Gitorious for that matter). Business cares not what it steamrolls in the
>> name of profit.
>> 
>> I fail to understand why, with multiple examples of the folly of this
>> belief out there, people are still willing to bet on *this* company being
>> *different* from all others and absolutely safe to trust.
> 
> What the heck is everyone arguing over? The initial statement was that
> even if we moved everything to github "We'd need mirroring anyway".
> That's it! There's no either/or involved. Just a statement that when
> you have data in one location, no matter how trustworthy, you want a
> backup as well. And ideally you want the backup under your control.
> 
> We can debate moving anything anywhere all we want, but the idea that
> stuff should also be backed up, regardless, in a source not under
> third-party control, seems inoffensive and besides the point.
> 
> --Gershom
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Can't push to haddock

[Gershom B]

> You're also assuming github doesn't suddenly pull a SourceForge (or a
> Gitorious for that matter). Business cares not what it steamrolls in the
> name of profit.
>
> I fail to understand why, with multiple examples of the folly of this
> belief out there, people are still willing to bet on *this* company being
> *different* from all others and absolutely safe to trust.

What the heck is everyone arguing over? The initial statement was that
even if we moved everything to github "We'd need mirroring anyway".
That's it! There's no either/or involved. Just a statement that when
you have data in one location, no matter how trustworthy, you want a
backup as well. And ideally you want the backup under your control.

We can debate moving anything anywhere all we want, but the idea that
stuff should also be backed up, regardless, in a source not under
third-party control, seems inoffensive and besides the point.

--Gershom
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Can't push to haddock

[Brandon Allbery]

On Tue, Dec 19, 2017 at 4:30 AM, Sven Panne  wrote:

> I think this is a question of perspective: Having the master repository on
> GitHub doesn't mean you are in immediate danger or lose your "family
> jewels". IMHO it's quite the contrary: I'm e.g. sure that in case that
> something goes wrong with GitHub, there is far more manpower behind it to
> fix that than for any self-hosted repository. And you can of course have
> some mirror of your GitHub repo in case of e.g. an earthquake/meteor/... in
> the San Francisco area... ;-)
>

You're also assuming github doesn't suddenly pull a SourceForge (or a
Gitorious for that matter). Business cares not what it steamrolls in the
name of profit.

I fail to understand why, with multiple examples of the folly of this
belief out there, people are still willing to bet on *this* company being
*different* from all others and absolutely safe to trust.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Can't push to haddock

[Sven Panne]

2017-12-19 12:47 GMT+01:00 Phyx :

> Cool, then let's turn to media reports then such as
> https://techcrunch.com/2017/07/31/github-goes-down-and-takes-developer-
> productivity-with-it/ do you have one for git.haskell.org going down?


Of course this question is a classic example of "the absence of evidence is
not the evidence of absence" fallacy, but anyway:

*
https://www.reddit.com/r/haskell/comments/4gppm8/ann_hackagehaskellorg_is_down/
* http://blog.haskell.org/post/4/outages_and_improvements.../
* Searchs ghc-devs@ for posts regarding Phabricator updates, Server moves,
problems with arc... (not exactly all downtimes, but in effect of the
incidents are the same)

I am not saying that the haskell.org infrastructure is bad, far from it,
but it would be an illusion to think that it has a much higher effective
uptime than GitHub. Furthermore: I don't think that the argument should
revolve around uptime. We have a distributed version control system where
people can happily work for an extended time span without *any* network at
all, and the GHC source repository is not a financial application which
would cause the loss of millions of dollars per minute if it's temporarily
unavailable. The arguments should be about simplicity, ease of use, etc.

Anyway, for my part the discussion is over, there *is* more or less open
hostility towards GitHub/more standardized environments here. Is it an
instance of the common "not invented here" syndrome or general mistrust in
any kind of organization? I don't know... :-/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Can't push to haddock

[Sven Panne]

2017-12-19 11:07 GMT+01:00 Phyx :

> These are just a few of the times github has been down in 2017
> http://currentlydown.com/github.com compared to haskell.org http://
> currentlydown.com/haskell.org [...]
>

I can't see any data for haskell.org on that page, apart from the fact that
it is up right now. Furthermore, I very much question the data on
currentlydown.com: According to it, Google, Facebook, YouTube, Yahoo! and
Amazon were down on March 25th for roughly an hour. A much more probable
explanation: currentlydown.com had problems, not the five of the biggest
sites in the world. This undermines the trust in the rest of the outage
reports a bit...
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Can't push to haddock

[Simon Peyton Jones via ghc-devs]

It seems to me that there is some hostility towards GitHub in GHC HQ, but I 
don't really understand why. GitHub serves other similar projects quite well, 
e.g. Rust, and I can't see why we should be special.
Speaking for myself, I have no hostility towards GitHub, and there is no GHC-HQ 
bias against it that I know of.  If it serves the purpose better, we should use 
it.   Indeed that’s why I asked my original question.  I agree with your point 
that data may actually be safer in GitHub than in our own repo.   (And there is 
nothing to stop a belt-and-braces mirror backup system.)

The issue is: does GitHub serve the purpose better?   We have frequently 
debated this multi-dimensional question.  And we should continue to do so: the 
answers may change over time (GitHub’s facilities are not static; and its 
increasing dominance is itself a cultural familiarity factor that simply was 
not the case five years ago).

Simon

From: Sven Panne [mailto:svenpa...@gmail.com]
Sent: 19 December 2017 09:30
To: Herbert Valerio Riedel <hvrie...@gmail.com>
Cc: Simon Peyton Jones <simo...@microsoft.com>; ghc-devs@haskell.org Devs 
<ghc-devs@haskell.org>
Subject: Re: Can't push to haddock

2017-12-19 9:50 GMT+01:00 Herbert Valerio Riedel 
<hvrie...@gmail.com<mailto:hvrie...@gmail.com>>:
We'd need mirroring anyway, as we want to keep control over our
infrastructure and not have to trust a 3rd party infrastructure to
safely handle our family jewels: GHC's source tree.

I think this is a question of perspective: Having the master repository on 
GitHub doesn't mean you are in immediate danger or lose your "family jewels". 
IMHO it's quite the contrary: I'm e.g. sure that in case that something goes 
wrong with GitHub, there is far more manpower behind it to fix that than for 
any self-hosted repository. And you can of course have some mirror of your 
GitHub repo in case of e.g. an earthquake/meteor/... in the San Francisco 
area... ;-)

It seems to me that there is some hostility towards GitHub in GHC HQ, but I 
don't really understand why. GitHub serves other similar projects quite well, 
e.g. Rust, and I can't see why we should be special.

Also, catching bad commits "a bit later" is just asking for trouble --
by the time they're caught the git repos have already lost their
invariant and its a big mess to recover;

This is by no means different than saying: "I want to run 'validate' in the 
commit hook, otherwise it's a big mess." We don't do this for obvious reasons, 
and what is the "big mess" if there is some incorrect submodule reference for a 
short time span? How is that different from somebody introducing e.g. a subtle 
compiler bug in a commit?

the invariant I devised and
whose validation I implemented 4 years ago has served us pretty well,
and has ensured that we never glitched into incorrectness; I'm also not
sure why it's being suggested to switch to a less principled and more
fragile scheme now. [...]

Because the whole repository structure is overly complicated and simply hosting 
everything on GitHub would simplify things. Again: I'm well aware that there 
are tradeoffs involved, but I would really appreciate simplifications. I have 
the impression that the entry barrier to GHC development has become larger and 
larger over the years, partly because of very non-standard tooling, partly 
because of the increasingly arcane repository organization. There are reasons 
that other projects like Rust attract far more developers... :-/


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Can't push to haddock

[Sven Panne]

2017-12-19 9:50 GMT+01:00 Herbert Valerio Riedel :

> We'd need mirroring anyway, as we want to keep control over our
> infrastructure and not have to trust a 3rd party infrastructure to
> safely handle our family jewels: GHC's source tree.
>

I think this is a question of perspective: Having the master repository on
GitHub doesn't mean you are in immediate danger or lose your "family
jewels". IMHO it's quite the contrary: I'm e.g. sure that in case that
something goes wrong with GitHub, there is far more manpower behind it to
fix that than for any self-hosted repository. And you can of course have
some mirror of your GitHub repo in case of e.g. an earthquake/meteor/... in
the San Francisco area... ;-)

It seems to me that there is some hostility towards GitHub in GHC HQ, but I
don't really understand why. GitHub serves other similar projects quite
well, e.g. Rust, and I can't see why we should be special.


> Also, catching bad commits "a bit later" is just asking for trouble --
> by the time they're caught the git repos have already lost their
> invariant and its a big mess to recover;


This is by no means different than saying: "I want to run 'validate' in the
commit hook, otherwise it's a big mess." We don't do this for obvious
reasons, and what is the "big mess" if there is some incorrect submodule
reference for a short time span? How is that different from somebody
introducing e.g. a subtle compiler bug in a commit?


> the invariant I devised and
> whose validation I implemented 4 years ago has served us pretty well,
> and has ensured that we never glitched into incorrectness; I'm also not
> sure why it's being suggested to switch to a less principled and more
> fragile scheme now. [...]


Because the whole repository structure is overly complicated and simply
hosting everything on GitHub would simplify things. Again: I'm well aware
that there are tradeoffs involved, but I would really appreciate
simplifications. I have the impression that the entry barrier to GHC
development has become larger and larger over the years, partly because of
very non-standard tooling, partly because of the increasingly arcane
repository organization. There are reasons that other projects like Rust
attract far more developers... :-/

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Can't push to haddock

[Herbert Valerio Riedel]

Hi,

On 2017-12-19 at 08:31:06 +0100, Sven Panne wrote:

> This is a tradeoff: Doing it that way, you catch incorrect commits a
> little bit later, but it makes the overall arcane repository magic
> quite a bit simpler, probably removing the need for mirroring.

We'd need mirroring anyway, as we want to keep control over our
infrastructure and not have to trust a 3rd party infrastructure to
safely handle our family jewels: GHC's source tree.

Also, catching bad commits "a bit later" is just asking for trouble --
by the time they're caught the git repos have already lost their
invariant and its a big mess to recover; the invariant I devised and
whose validation I implemented 4 years ago has served us pretty well,
and has ensured that we never glitched into incorrectness; I'm also not
sure why it's being suggested to switch to a less principled and more
fragile scheme now. As a Haskell programmer, I rather err on the side of
correctness for mission critical things, and shifting checks we can (and
already) do statically to CI feels to me like embracing
`-fdefer-type-errors`... :-)

Cheers,
  HVR
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Can't push to haddock

[Sven Panne]

2017-12-18 17:01 GMT+01:00 Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org>:

> |  It's for technical reasons, and the strongest one being: GitHub doesn't
> |  allow us to establish strong invariants regarding submodule gitlink
> |  referential integrity for submodules (which I implemented a couple
> years ago
> |  for git.haskell.org).
>
> Interesting.  It'd be good to document what the technical reasons are.
> For example I don’t know what the strong invariants are. [...]
>

Me neither. :-] Looking at the repositories Wiki page, it seems to be
related to the fact that GitHub doesn't offer git hooks, which are used to
check the invariants. This leads to another question: Is it *really*
necessary to have the invariant checks implemented as a git hook? If you
use any kind of continuous integration, which GHC obviously does, one can
move the checks to e.g. CircleCI (or whatever CI is used). This is a
tradeoff: Doing it that way, you catch incorrect commits a little bit
later, but it makes the overall arcane repository magic quite a bit
simpler, probably removing the need for mirroring. This seems to be a good
tradeoff, but of course I might be missing some details here.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Can't push to haddock

[Simon Peyton Jones via ghc-devs]

|  It's for technical reasons, and the strongest one being: GitHub doesn't
|  allow us to establish strong invariants regarding submodule gitlink
|  referential integrity for submodules (which I implemented a couple years ago
|  for git.haskell.org).

Interesting.  It'd be good to document what the technical reasons are.  For 
example I don’t know what the strong invariants are.

A good place to describe them might be the Repositories pages
https://ghc.haskell.org/trac/ghc/wiki/Repositories

Many thanks

Simon

|  -Original Message-
|  From: Herbert Valerio Riedel [mailto:hvrie...@gmail.com]
|  Sent: 18 December 2017 11:13
|  To: Simon Peyton Jones <simo...@microsoft.com>
|  Subject: Re: Can't push to haddock
|  
|  On Mon, Dec 18, 2017 at 10:01 AM, Simon Peyton Jones via ghc-devs  wrote:
|  > But why don’t we just pull from github rather than mirroring on
|  > git.haskell.org?
|  
|  It's for technical reasons, and the strongest one being: GitHub doesn't
|  allow us to establish strong invariants regarding submodule gitlink
|  referential integrity for submodules (which I implemented a couple years ago
|  for git.haskell.org).
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Can't push to haddock

[Simon Peyton Jones via ghc-devs]

|  Yes, the mirroring has a little bit of latency (assuming the mirroring
|  trigger event notification from github to git.haskell.org didn't get
|  lost). How much time did you wait between pushing to github and
|  ghc.git?

I didn't allow any time -- I didn't know that time was needed. Perhaps we 
should add a note to 
https://ghc.haskell.org/trac/ghc/wiki/Repositories
to explain?  Under "Updating sub-repos" perhaps.

I wonder if it'd be worth us articulating the reason why some submodules live 
in github, but some live in git.haskell.org -- with only mirroring github.  I'm 
sure there's a rationale but I don't get it yet.

Simon


|  -Original Message-
|  From: Herbert Valerio Riedel [mailto:hvrie...@gmail.com]
|  Sent: 07 December 2017 17:57
|  To: Simon Peyton Jones <simo...@microsoft.com>
|  Subject: Re: Can't push to haddock
|  
|  Hi Simon,
|  
|  Yes, the mirroring has a little bit of latency (assuming the mirroring
|  trigger event notification from github to git.haskell.org didn't get
|  lost). How much time did you wait between pushing to github and
|  ghc.git?
|  
|  On Thu, Dec 7, 2017 at 6:53 PM, Simon Peyton Jones via ghc-devs  wrote:
|  > But when I try to push the GHC patch, I get this message
|  >
|  > Ah… it worked after a while. Maybe a mirroring thing?
|  >
|  > But in pushing to GHC I saw:
|  >
|  > git push
|  >
|  > Counting objects: 45, done.
|  >
|  > Delta compression using up to 32 threads.
|  >
|  > Compressing objects: 100% (45/45), done.
|  >
|  > Writing objects: 100% (45/45), 27.56 KiB | 0 bytes/s, done.
|  >
|  > Total 45 (delta 43), reused 0 (delta 0)
|  >
|  > remote: performing commit message validations...
|  >
|  > remote: Commit message validation passed!
|  >
|  > remote: performing submodule-ref update validations...
|  >
|  > remote: Submodule update(s) detected in
|  > fa29df02a1b0b926afb2525a258172dcbf0ea460:
|  >
|  > remote:  utils/haddock => 24841386cff6fdccc11accf9daa815c2c7444d65
|  >
|  > remote:  utils/hsc2hs => 9483ad10064fbbb97ab525280623826b1ef63959
|  >
|  > remote:  OK
|  >
|  > remote: performing whitespace validations...
|  >
|  > remote: whitespace validation passed!
|  >
|  > remote: mirroring ssh://g...@git.haskell.org/ghc to
|  > ssh://g...@github.com/ghc/ghc ...
|  >
|  > remote: To ssh://g...@github.com/ghc/ghc
|  >
|  > remote:5f332e1..fa29df0  master -> master
|  >
|  > remote: running notifier
|  >
|  > To ssh://g...@git.haskell.org/ghc.git
|  >
|  >5f332e1..fa29df0  HEAD -> master
|  >
|  > simonpj@cam-05-unx:~/code/HEAD$
|  >
|  > I did not intend to monkey around with hsc2hs. I can’t think how
|  that
|  > happened, or whether it matter.
|  >
|  > With many apologies, would a wiser person that me like to see if
|  I’ve
|  > accidentally messed up hsc2hs.
|  >
|  > Thanks
|  >
|  > Simon
|  >
|  >
|  >
|  > From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
|  > Simon Peyton Jones via ghc-devs
|  > Sent: 07 December 2017 17:32
|  > To: ghc-devs@haskell.org
|  > Subject: Can't push to haddock
|  >
|  >
|  >
|  > I’m trying to push a patch that needs a supporting change to
|  haddock.
|  >
|  > I’ve pushed the haddock change to the ghc-head branch of
|  > ssh://g...@github.com/haskell/haddock.git, which is (according to
|  > ‘packages’) the relevant haddock upstream repo.
|  >
|  > But when I try to push the GHC patch, I get this message
|  >
|  > bash$ git push
|  >
|  > Counting objects: 45, done.
|  >
|  > Delta compression using up to 32 threads.
|  >
|  > Compressing objects: 100% (45/45), done.
|  >
|  > Writing objects: 100% (45/45), 27.56 KiB | 0 bytes/s, done.
|  >
|  > Total 45 (delta 43), reused 0 (delta 0)
|  >
|  > remote: performing commit message validations...
|  >
|  > remote: Commit message validation passed!
|  >
|  > remote: performing submodule-ref update validations...
|  >
|  > remote: Submodule update(s) detected in
|  > fa29df02a1b0b926afb2525a258172dcbf0ea460:
|  >
|  > remote:  utils/haddock => 24841386cff6fdccc11accf9daa815c2c7444d65
|  >
|  > remote: *FAIL* commit not found in submodule repo ('../haddock.git')
|  >
|  > remote:or not reachable from persistent branches
|  >
|  > remote: hooklet hooks/update.secondary.d/check-submodule-refs failed
|  >
|  > remote: hooks/update.secondary died
|  >
|  > remote: error: hook declined to update refs/heads/master
|  >
|  > To ssh://g...@git.haskell.org/ghc.git
|  >
|  > ! [remote rejected] HEAD -> master (hook declined)
|  >
|  > error: failed to push some refs to
|  'ssh://g...@git.haskell.org/ghc.git'
|  >
|  > simonpj@cam-05-unx:~/c

RE: Can't push to haddock

[Simon Peyton Jones via ghc-devs]

But when I try to push the GHC patch, I get this message
Ah... it worked after a while. Maybe a mirroring thing?
But in pushing to GHC I saw:

git push

Counting objects: 45, done.

Delta compression using up to 32 threads.

Compressing objects: 100% (45/45), done.

Writing objects: 100% (45/45), 27.56 KiB | 0 bytes/s, done.

Total 45 (delta 43), reused 0 (delta 0)

remote: performing commit message validations...

remote: Commit message validation passed!

remote: performing submodule-ref update validations...

remote: Submodule update(s) detected in 
fa29df02a1b0b926afb2525a258172dcbf0ea460:

remote:  utils/haddock => 24841386cff6fdccc11accf9daa815c2c7444d65

remote:  utils/hsc2hs => 9483ad10064fbbb97ab525280623826b1ef63959

remote:  OK

remote: performing whitespace validations...

remote: whitespace validation passed!

remote: mirroring ssh://g...@git.haskell.org/ghc to 
ssh://g...@github.com/ghc/ghc ...

remote: To ssh://g...@github.com/ghc/ghc

remote:5f332e1..fa29df0  master -> master

remote: running notifier

To ssh://g...@git.haskell.org/ghc.git

   5f332e1..fa29df0  HEAD -> master

simonpj@cam-05-unx:~/code/HEAD$
I did not intend to monkey around with hsc2hs. I can't think how that happened, 
or whether it matter.
With many apologies, would a wiser person that me like to see if I've 
accidentally messed up hsc2hs.
Thanks
Simon

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Simon Peyton 
Jones via ghc-devs
Sent: 07 December 2017 17:32
To: ghc-devs@haskell.org
Subject: Can't push to haddock

I'm trying to push a patch that needs a supporting change to haddock.
I've pushed the haddock change to the ghc-head branch of 
ssh://g...@github.com/haskell/haddock.git, which is (according to 'packages') 
the relevant haddock upstream repo.
But when I try to push the GHC patch, I get this message

bash$ git push

Counting objects: 45, done.

Delta compression using up to 32 threads.

Compressing objects: 100% (45/45), done.

Writing objects: 100% (45/45), 27.56 KiB | 0 bytes/s, done.

Total 45 (delta 43), reused 0 (delta 0)

remote: performing commit message validations...

remote: Commit message validation passed!

remote: performing submodule-ref update validations...

remote: Submodule update(s) detected in 
fa29df02a1b0b926afb2525a258172dcbf0ea460:

remote:  utils/haddock => 24841386cff6fdccc11accf9daa815c2c7444d65

remote: *FAIL* commit not found in submodule repo ('../haddock.git')

remote:or not reachable from persistent branches

remote: hooklet hooks/update.secondary.d/check-submodule-refs failed

remote: hooks/update.secondary died

remote: error: hook declined to update refs/heads/master

To ssh://g...@git.haskell.org/ghc.git

! [remote rejected] HEAD -> master (hook declined)

error: failed to push some refs to 'ssh://g...@git.haskell.org/ghc.git'

simonpj@cam-05-unx:~/code/HEAD$


What's up?  I  have pushed the haddock commit!
THanks
Simon


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Can't push to haddock

[Simon Peyton Jones via ghc-devs]

I'm trying to push a patch that needs a supporting change to haddock.
I've pushed the haddock change to the ghc-head branch of 
ssh://g...@github.com/haskell/haddock.git, which is (according to 'packages') 
the relevant haddock upstream repo.
But when I try to push the GHC patch, I get this message

bash$ git push

Counting objects: 45, done.

Delta compression using up to 32 threads.

Compressing objects: 100% (45/45), done.

Writing objects: 100% (45/45), 27.56 KiB | 0 bytes/s, done.

Total 45 (delta 43), reused 0 (delta 0)

remote: performing commit message validations...

remote: Commit message validation passed!

remote: performing submodule-ref update validations...

remote: Submodule update(s) detected in 
fa29df02a1b0b926afb2525a258172dcbf0ea460:

remote:  utils/haddock => 24841386cff6fdccc11accf9daa815c2c7444d65

remote: *FAIL* commit not found in submodule repo ('../haddock.git')

remote:or not reachable from persistent branches

remote: hooklet hooks/update.secondary.d/check-submodule-refs failed

remote: hooks/update.secondary died

remote: error: hook declined to update refs/heads/master

To ssh://g...@git.haskell.org/ghc.git

! [remote rejected] HEAD -> master (hook declined)

error: failed to push some refs to 'ssh://g...@git.haskell.org/ghc.git'

simonpj@cam-05-unx:~/code/HEAD$


What's up?  I  have pushed the haddock commit!
THanks
Simon


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Can't push to haddock repo

[Ben Gamari]

Simon Peyton Jones  writes:

> Well in utils/haddock/.git/config I see
> [remote "origin"]
>   url = git://git.haskell.org/haddock.git
>   pushurl = ssh://g...@git.haskell.org/haddock.git
>
Note the difference in hostnames,

   ssh://g...@git.haskell.org/haddock.git
 ssh://g...@github.com/haskell/haddock.git 

The point being, Haddock is hosted on Github. I believe the repo on
git.haskell.org is merely a mirror.

It's a bit hard to keep track of all of this at times, so the upstream
repositories are documented in the `packages` file at the root of the
GHC repository.

Cheers,

- Ben



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Can't push to haddock repo

[Simon Peyton Jones]

I can't update the haddock repository!   (I want to add a new branch for my 
in-flight work.)
Can anyone help?
Thanks
Simon


git push --set-upstream origin wip/spj-wildcard-refactor

remote: W refs/heads/wip/spj-wildcard-refactor haddock simonpj DENIED by refs/.*

remote: error: hook declined to update refs/heads/wip/spj-wildcard-refactor

To ssh://g...@git.haskell.org/haddock.git

! [remote rejected] wip/spj-wildcard-refactor -> wip/spj-wildcard-refactor 
(hook declined)

error: failed to push some refs to 'ssh://g...@git.haskell.org/haddock.git'

haddock $
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Can't push to haddock repo

[Herbert Valerio Riedel]

In the GHC tree:

$ grep haddock packages 
utils/haddock-   -   
ssh://g...@github.com/haskell/haddock.git

says that the upstream repo for Haddock is ssh://...

(there are some comments in the 'packages' file that explain what the
last column means)

so you have to do something like

  git push ssh://g...@github.com/haskell/haddock.git 
HEAD:wip/spj-wildcard-refactor

(the 'HEAD:' part may be optional, it just says, push what is the
current HEAD of your local repo to the remote branch wip/...)

HTH

On 2015-10-26 at 13:57:55 +0100, Simon Peyton Jones wrote:
> I can't update the haddock repository!   (I want to add a new branch for my 
> in-flight work.)
> Can anyone help?
> Thanks
> Simon
>
>
> git push --set-upstream origin wip/spj-wildcard-refactor
>
> remote: W refs/heads/wip/spj-wildcard-refactor haddock simonpj DENIED by 
> refs/.*
>
> remote: error: hook declined to update refs/heads/wip/spj-wildcard-refactor
>
> To ssh://g...@git.haskell.org/haddock.git
>
> ! [remote rejected] wip/spj-wildcard-refactor -> wip/spj-wildcard-refactor 
> (hook declined)
>
> error: failed to push some refs to 'ssh://g...@git.haskell.org/haddock.git'
>
> haddock $
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-- 
"Elegance is not optional" -- Richard O'Keefe
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Can't push to haddock repo

[Simon Peyton Jones]

Well in utils/haddock/.git/config I see
[remote "origin"]
url = git://git.haskell.org/haddock.git
pushurl = ssh://g...@git.haskell.org/haddock.git

So that looks right.  Why would git push not work?

Simon

| -Original Message-
| From: Herbert Valerio Riedel [mailto:hvrie...@gmail.com]
| Sent: 26 October 2015 13:04
| To: Simon Peyton Jones
| Cc: ghc-devs@haskell.org
| Subject: Re: Can't push to haddock repo
| 
| 
| In the GHC tree:
| 
| $ grep haddock packages
| utils/haddock-   -
| ssh://g...@github.com/haskell/haddock.git
| 
| says that the upstream repo for Haddock is ssh://...
| 
| (there are some comments in the 'packages' file that explain what the
| last column means)
| 
| so you have to do something like
| 
|   git push ssh://g...@github.com/haskell/haddock.git HEAD:wip/spj-wildcard-
| refactor
| 
| (the 'HEAD:' part may be optional, it just says, push what is the
| current HEAD of your local repo to the remote branch wip/...)
| 
| HTH
| 
| On 2015-10-26 at 13:57:55 +0100, Simon Peyton Jones wrote:
| > I can't update the haddock repository!   (I want to add a new branch for
| my in-flight work.)
| > Can anyone help?
| > Thanks
| > Simon
| >
| >
| > git push --set-upstream origin wip/spj-wildcard-refactor
| >
| > remote: W refs/heads/wip/spj-wildcard-refactor haddock simonpj DENIED by
| refs/.*
| >
| > remote: error: hook declined to update refs/heads/wip/spj-wildcard-
| refactor
| >
| > To ssh://g...@git.haskell.org/haddock.git
| >
| > ! [remote rejected] wip/spj-wildcard-refactor -> wip/spj-wildcard-
| refactor (hook declined)
| >
| > error: failed to push some refs to
| 'ssh://g...@git.haskell.org/haddock.git'
| >
| > haddock $
| > ___
| > ghc-devs mailing list
| > ghc-devs@haskell.org
| >
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskel
| l.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
| devs=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c8b244454862541a00577
| 08d2de05db9f%7c72f988bf86f141af91ab2d7cd011db47%7c1=kCypWx5Kq7ffV9piW
| ItQNerjzDLU68rgHUacMsV%2f5pk%3d
| 
| --
| "Elegance is not optional" -- Richard O'Keefe
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Can't push to haddock repo

[Simon Peyton Jones]

ah yes, my bad. Thanks

|  -Original Message-
|  From: Ben Gamari [mailto:b...@well-typed.com]
|  Sent: 26 October 2015 13:55
|  To: Simon Peyton Jones; Herbert Valerio Riedel
|  Cc: ghc-devs@haskell.org
|  Subject: RE: Can't push to haddock repo
|  
|  Simon Peyton Jones <simo...@microsoft.com> writes:
|  
|  > Well in utils/haddock/.git/config I see [remote "origin"]
|  >url = git://git.haskell.org/haddock.git
|  >pushurl = ssh://g...@git.haskell.org/haddock.git
|  >
|  Note the difference in hostnames,
|  
|  ssh://g...@git.haskell.org/haddock.git
|   ssh://g...@github.com/haskell/haddock.git
|  
|  The point being, Haddock is hosted on Github. I believe the repo on
|  git.haskell.org is merely a mirror.
|  
|  It's a bit hard to keep track of all of this at times, so the upstream
|  repositories are documented in the `packages` file at the root of the GHC
|  repository.
|  
|  Cheers,
|  
|  - Ben

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs