Re: Haddock tree spongled

[Spiwack, Arnaud]

What is this bad state?

I think the problem is that if you don’t push to haddock/ghc-head first,
then the commit in ghc/master would point to a commit which has no
guarantee to be durable: it may be rebased or squashed, by the time it gets
to ghc-head. This means that after the commit has been mutated, the commit
in ghc is no longer a valid checkout (because it can’t checkout its Haddock
submodule).

In the current situation, it is imperative that haddock/ghc-head is updated
first. If we want to preserve the most minimal of invariant. It is still a
pretty awful situation to be in, to be honest.

   - It’s rather hard to enforce, so if one forgets to update
   haddock/ghc-head first, then we are back to square one. (I suppose that, in
   constrast, in Matthew’s linter change, we would have red CI during the
   entire review phase of an MR. Which would be rather inconvenient, to say
   the least)
   - You need two independent sets of approval to get either part of a
   patch merged.
   - Two MR which want to modify Haddock will needlessly conflict with one
   another. When one has its Haddock modification merged. The other requires
   updates (it’s super tedious to rebase a history and be clean if there are
   several commit which touch Haddock, by the way). And trigger unnecessary
   consumption of our already precious CI resources.
   - In fact, any merging of a change to haddock/ghc-head will require
   rewriting the history of the MR that needs it. Also unnecessary consumption
   of CI resources.

Quite frankly, this is not a fun place to be. It may be worth taking a step
back and contemplating the situation we’ve built for ourselves.

/Arnaud

On Wed, Mar 13, 2019 at 3:19 PM Alec Theriault 
wrote:

> Under your workflow it doesn't seem like the commit which ends up in
> master will point to a commit on ghc-head?
>
>
> Correct, but at most the head commit will be out of sync (and a fast
> forward merge should be always possible). Step 3 is about rectifying that
> situation.
>
> This is problematic when doing bisection if the branch where the
> commit lives is deleted or force pushed to.
>
>
> We still end up with an easy-to-bisect linear history (in both Haddock and
> GHC) at the end of the day. I fear I may be misunderstanding your point
> here.
>
> I would prefer a workflow which is more annoying for contributors but
> doesn't leave the tree in a bad state than one which is convenient but
> dangerous.
>
>
> What is this bad state? Perhaps I’m again misunderstanding, but how does
> your proposal help leave the tree in a better state? As soon as someone
> preparing a GHC patch pushes changes directly to ghc-head and before
> those changes get merged, the situation is going to be just as confusing
> for everyone else trying to do something with Haddock (and not easily
> fixable either).
>
> Thanks,
> Alec
>
> On Mar 13, 2019, at 6:59 AM, Matthew Pickering <
> matthewtpicker...@gmail.com> wrote:
>
> Under your workflow it doesn't seem like the commit which ends up in
> master will point to a commit on ghc-head?
>
> This is problematic when doing bisection if the branch where the
> commit lives is deleted or force pushed to.
>
> I would prefer a workflow which is more annoying for contributors but
> doesn't leave the tree in a bad state than one which is convenient but
> dangerous.
>
> Cheers,
>
> Matt
>
> On Wed, Mar 13, 2019 at 1:42 PM Alec Theriault 
> wrote:
>
>
> Hi,
>
> The currently recommended workflow is that your commit should be in
> the ghc-head branch before the merge to GHC takes place. This enforces
>
>
> This seems problematic: everyone is going to race to get their changes
> into Haddock's ghc-head first, then block everyone else’s Haddock-touching
> patches from building with CI until the GHC side of the first person's
> changes goes through too. And that might take some time if Marge finds
> problems with the patch. I propose the workflow be:
>
> Once you’ve finished your patch, rebase the GHC side on top of upstream
> GHC master
> Rebase the Haddock side on top of upstream Haddock ghc-head
> Once Marge merges your MR, fast-forward the upstream ghc-head to your new
> commit
>
>
> That way, multiple MR’s with Haddock parts can “race” to get merged.
> Whoever loses just has to rebase. Ideally, we would have Marge doing both
> the rebasing and step #3 for us. In the place of Marge, anyone who has
> write access to Haddock should feel free to do step #3 too (like when Marge
> merges an MR while the author of the MR is busy doing other things… like
> sleeping).
>
> As a side note, I do wish there was an easy way in GitLab to quickly jump
> to the diffs of submodules (or at least an easy way to copy the new commit
> hash).
>
> Thanks,
> Alec
>
> On Mar 13, 2019, at 4:13 AM, Matthew Pickering <
> matthewtpicker...@gmail.com> wrote:
>
> I tried adding back the linters which check to make sure a commit is
> in the upstream branch before a MR is merged but got blocked by a
> gitlab issue.
>
> 

Re: Haddock tree spongled

[Alec Theriault]

> Under your workflow it doesn't seem like the commit which ends up in
> master will point to a commit on ghc-head?


Correct, but at most the head commit will be out of sync (and a fast forward 
merge should be always possible). Step 3 is about rectifying that situation.

> This is problematic when doing bisection if the branch where the
> commit lives is deleted or force pushed to.


We still end up with an easy-to-bisect linear history (in both Haddock and GHC) 
at the end of the day. I fear I may be misunderstanding your point here.

> I would prefer a workflow which is more annoying for contributors but
> doesn't leave the tree in a bad state than one which is convenient but
> dangerous.


What is this bad state? Perhaps I’m again misunderstanding, but how does your 
proposal help leave the tree in a better state? As soon as someone preparing a 
GHC patch pushes changes directly to ghc-head and before those changes get 
merged, the situation is going to be just as confusing for everyone else trying 
to do something with Haddock (and not easily fixable either).

Thanks,
Alec

> On Mar 13, 2019, at 6:59 AM, Matthew Pickering  
> wrote:
> 
> Under your workflow it doesn't seem like the commit which ends up in
> master will point to a commit on ghc-head?
> 
> This is problematic when doing bisection if the branch where the
> commit lives is deleted or force pushed to.
> 
> I would prefer a workflow which is more annoying for contributors but
> doesn't leave the tree in a bad state than one which is convenient but
> dangerous.
> 
> Cheers,
> 
> Matt
> 
> On Wed, Mar 13, 2019 at 1:42 PM Alec Theriault  
> wrote:
>> 
>> Hi,
>> 
>> The currently recommended workflow is that your commit should be in
>> the ghc-head branch before the merge to GHC takes place. This enforces
>> 
>> 
>> This seems problematic: everyone is going to race to get their changes into 
>> Haddock's ghc-head first, then block everyone else’s Haddock-touching 
>> patches from building with CI until the GHC side of the first person's 
>> changes goes through too. And that might take some time if Marge finds 
>> problems with the patch. I propose the workflow be:
>> 
>> Once you’ve finished your patch, rebase the GHC side on top of upstream GHC 
>> master
>> Rebase the Haddock side on top of upstream Haddock ghc-head
>> Once Marge merges your MR, fast-forward the upstream ghc-head to your new 
>> commit
>> 
>> 
>> That way, multiple MR’s with Haddock parts can “race” to get merged. Whoever 
>> loses just has to rebase. Ideally, we would have Marge doing both the 
>> rebasing and step #3 for us. In the place of Marge, anyone who has write 
>> access to Haddock should feel free to do step #3 too (like when Marge merges 
>> an MR while the author of the MR is busy doing other things… like sleeping).
>> 
>> As a side note, I do wish there was an easy way in GitLab to quickly jump to 
>> the diffs of submodules (or at least an easy way to copy the new commit 
>> hash).
>> 
>> Thanks,
>> Alec
>> 
>> On Mar 13, 2019, at 4:13 AM, Matthew Pickering  
>> wrote:
>> 
>> I tried adding back the linters which check to make sure a commit is
>> in the upstream branch before a MR is merged but got blocked by a
>> gitlab issue.
>> 
>> https://gitlab.haskell.org/ghc/ghc/merge_requests/395
>> 
>> The currently recommended workflow is that your commit should be in
>> the ghc-head branch before the merge to GHC takes place. This enforces
>> some linearisation but it stops the tree breaking.
>> 
>> Matt
>> 
>> On Wed, Mar 13, 2019 at 9:17 AM Spiwack, Arnaud  
>> wrote:
>> 
>> 
>> 
>> On Wed, Mar 6, 2019 at 11:04 PM Alec Theriault  
>> wrote:
>> 
>> 
>> The right way to solve this problem is probably to find a better way of 
>> factoring GHC-specific functionality out and putting only that in the GHC 
>> tree. This is a good long term goal, but I don’t think we are quite there 
>> yet. Some other ongoing changes in both GHC and Haddock are blocking the way 
>> forward on this front…
>> 
>> 
>> 
>> In the meantime, there is no way to make atomic updates to GHC and Haddock 
>> (which need to happen regularly). And GHC's master and the ghc-head branch 
>> keep getting out of sync. It's really hard to diagnose, until it blocks 
>> someone's valuable time. At which point it's too late.
>> 
>> Is there a short term solution which would alleviate that cost, besides 
>> merging Haddock in the main Ghc tree?
>> ___
>> 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: Haddock tree spongled

[Matthew Pickering]

Under your workflow it doesn't seem like the commit which ends up in
master will point to a commit on ghc-head?

This is problematic when doing bisection if the branch where the
commit lives is deleted or force pushed to.

I would prefer a workflow which is more annoying for contributors but
doesn't leave the tree in a bad state than one which is convenient but
dangerous.

Cheers,

Matt

On Wed, Mar 13, 2019 at 1:42 PM Alec Theriault  wrote:
>
> Hi,
>
> The currently recommended workflow is that your commit should be in
> the ghc-head branch before the merge to GHC takes place. This enforces
>
>
> This seems problematic: everyone is going to race to get their changes into 
> Haddock's ghc-head first, then block everyone else’s Haddock-touching patches 
> from building with CI until the GHC side of the first person's changes goes 
> through too. And that might take some time if Marge finds problems with the 
> patch. I propose the workflow be:
>
> Once you’ve finished your patch, rebase the GHC side on top of upstream GHC 
> master
> Rebase the Haddock side on top of upstream Haddock ghc-head
> Once Marge merges your MR, fast-forward the upstream ghc-head to your new 
> commit
>
>
> That way, multiple MR’s with Haddock parts can “race” to get merged. Whoever 
> loses just has to rebase. Ideally, we would have Marge doing both the 
> rebasing and step #3 for us. In the place of Marge, anyone who has write 
> access to Haddock should feel free to do step #3 too (like when Marge merges 
> an MR while the author of the MR is busy doing other things… like sleeping).
>
> As a side note, I do wish there was an easy way in GitLab to quickly jump to 
> the diffs of submodules (or at least an easy way to copy the new commit hash).
>
> Thanks,
> Alec
>
> On Mar 13, 2019, at 4:13 AM, Matthew Pickering  
> wrote:
>
> I tried adding back the linters which check to make sure a commit is
> in the upstream branch before a MR is merged but got blocked by a
> gitlab issue.
>
> https://gitlab.haskell.org/ghc/ghc/merge_requests/395
>
> The currently recommended workflow is that your commit should be in
> the ghc-head branch before the merge to GHC takes place. This enforces
> some linearisation but it stops the tree breaking.
>
> Matt
>
> On Wed, Mar 13, 2019 at 9:17 AM Spiwack, Arnaud  
> wrote:
>
>
>
> On Wed, Mar 6, 2019 at 11:04 PM Alec Theriault  
> wrote:
>
>
> The right way to solve this problem is probably to find a better way of 
> factoring GHC-specific functionality out and putting only that in the GHC 
> tree. This is a good long term goal, but I don’t think we are quite there 
> yet. Some other ongoing changes in both GHC and Haddock are blocking the way 
> forward on this front…
>
>
>
> In the meantime, there is no way to make atomic updates to GHC and Haddock 
> (which need to happen regularly). And GHC's master and the ghc-head branch 
> keep getting out of sync. It's really hard to diagnose, until it blocks 
> someone's valuable time. At which point it's too late.
>
> Is there a short term solution which would alleviate that cost, besides 
> merging Haddock in the main Ghc tree?
> ___
> 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: Haddock tree spongled

[Alec Theriault]

Hi,

> The currently recommended workflow is that your commit should be in
> the ghc-head branch before the merge to GHC takes place. This enforces


This seems problematic: everyone is going to race to get their changes into 
Haddock's ghc-head first, then block everyone else’s Haddock-touching patches 
from building with CI until the GHC side of the first person's changes goes 
through too. And that might take some time if Marge finds problems with the 
patch. I propose the workflow be:

Once you’ve finished your patch, rebase the GHC side on top of upstream GHC 
master
Rebase the Haddock side on top of upstream Haddock ghc-head
Once Marge merges your MR, fast-forward the upstream ghc-head to your new commit
  
That way, multiple MR’s with Haddock parts can “race” to get merged. Whoever 
loses just has to rebase. Ideally, we would have Marge doing both the rebasing 
and step #3 for us. In the place of Marge, anyone who has write access to 
Haddock should feel free to do step #3 too (like when Marge merges an MR while 
the author of the MR is busy doing other things… like sleeping).

As a side note, I do wish there was an easy way in GitLab to quickly jump to 
the diffs of submodules (or at least an easy way to copy the new commit hash).

Thanks,
Alec

> On Mar 13, 2019, at 4:13 AM, Matthew Pickering  
> wrote:
> 
> I tried adding back the linters which check to make sure a commit is
> in the upstream branch before a MR is merged but got blocked by a
> gitlab issue.
> 
> https://gitlab.haskell.org/ghc/ghc/merge_requests/395
> 
> The currently recommended workflow is that your commit should be in
> the ghc-head branch before the merge to GHC takes place. This enforces
> some linearisation but it stops the tree breaking.
> 
> Matt
> 
> On Wed, Mar 13, 2019 at 9:17 AM Spiwack, Arnaud  
> wrote:
>> 
>> 
>> On Wed, Mar 6, 2019 at 11:04 PM Alec Theriault  
>> wrote:
>>> 
>>> The right way to solve this problem is probably to find a better way of 
>>> factoring GHC-specific functionality out and putting only that in the GHC 
>>> tree. This is a good long term goal, but I don’t think we are quite there 
>>> yet. Some other ongoing changes in both GHC and Haddock are blocking the 
>>> way forward on this front…
>> 
>> 
>> In the meantime, there is no way to make atomic updates to GHC and Haddock 
>> (which need to happen regularly). And GHC's master and the ghc-head branch 
>> keep getting out of sync. It's really hard to diagnose, until it blocks 
>> someone's valuable time. At which point it's too late.
>> 
>> Is there a short term solution which would alleviate that cost, besides 
>> merging Haddock in the main Ghc tree?
>> ___
>> 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: Haddock tree spongled

[Matthew Pickering]

I tried adding back the linters which check to make sure a commit is
in the upstream branch before a MR is merged but got blocked by a
gitlab issue.

https://gitlab.haskell.org/ghc/ghc/merge_requests/395

The currently recommended workflow is that your commit should be in
the ghc-head branch before the merge to GHC takes place. This enforces
some linearisation but it stops the tree breaking.

Matt

On Wed, Mar 13, 2019 at 9:17 AM Spiwack, Arnaud  wrote:
>
>
> On Wed, Mar 6, 2019 at 11:04 PM Alec Theriault  
> wrote:
>>
>> The right way to solve this problem is probably to find a better way of 
>> factoring GHC-specific functionality out and putting only that in the GHC 
>> tree. This is a good long term goal, but I don’t think we are quite there 
>> yet. Some other ongoing changes in both GHC and Haddock are blocking the way 
>> forward on this front…
>
>
> In the meantime, there is no way to make atomic updates to GHC and Haddock 
> (which need to happen regularly). And GHC's master and the ghc-head branch 
> keep getting out of sync. It's really hard to diagnose, until it blocks 
> someone's valuable time. At which point it's too late.
>
> Is there a short term solution which would alleviate that cost, besides 
> merging Haddock in the main Ghc tree?
> ___
> 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: Haddock tree spongled

[Spiwack, Arnaud]

On Wed, Mar 6, 2019 at 11:04 PM Alec Theriault 
wrote:

> The right way to solve this problem is probably to find a better way of
> factoring GHC-specific functionality out and putting only that in the GHC
> tree. This is a good long term goal, but I don’t think we are quite there
> yet. Some other ongoing changes in both GHC and Haddock are blocking the
> way forward on this front…
>

In the meantime, there is no way to make atomic updates to GHC and Haddock
(which need to happen regularly). And GHC's master and the ghc-head branch
keep getting out of sync. It's really hard to diagnose, until it blocks
someone's valuable time. At which point it's too late.

Is there a short term solution which would alleviate that cost, besides
merging Haddock in the main Ghc tree?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Haddock tree spongled

[Alec Theriault]

Merging Haddock into GHC’s subtree would undoubtedly simplify the GHC workflow 
for patches affecting Haddock. There are a couple other considerations though:
Haddock currently sees the bulk of its contributions and bug fixes on its 
stable branches, not the ghc-head branch (which is the one GHC tracks). Not 
only is this exactly the opposite of GHC, but it also makes outside 
contributions and CI much simpler.
The Haddock project is actually 3 packages, two of which are libraries, one of 
which is expected to build on GHC going all the way back to the 7.4.* series. 
AFAICT, the packages kept in GHC’s source tree usually advance in lockstep with 
GHC.
Running the full GHC CI for most of Haddock’s changes seems a waste of 
resources and an unnecessary delay. Besides, Haddock actually has a larger test 
suite, which is only expected to compile on the stable branch (although I try 
to keep it running on ghc-head with the help of head.hackage). I recently 
incorporated the other part of Haddock’s testsuite into GHC’s testsuite, so I’m 
hoping there will be less breakage coming from ghc-head.
Interleaving git histories would (mostly) just make bisecting both GHC and 
Haddock more of a pain.
The right way to solve this problem is probably to find a better way of 
factoring GHC-specific functionality out and putting only that in the GHC tree. 
This is a good long term goal, but I don’t think we are quite there yet. Some 
other ongoing changes in both GHC and Haddock are blocking the way forward on 
this front…

Thanks,
Alec

> On Mar 6, 2019, at 1:26 PM, Boespflug, Mathieu  wrote:
> 
> If the status quo is poor, then why not merge the two? git-subtree won't fix 
> the problem and will arguably be even harder to manage than submodules.
> 
> Best,
> 
> On Wed, 6 Mar 2019 at 15:59, Ben Gamari  > wrote:
> Sylvain Henry mailto:sylv...@haskus.fr>> writes:
> 
> > Why don't we just put Haddock into GHC's repository? It was proposed in 
> > a previous discussion in February [1] and it would avoid the bad 
> > experience of having it as a submodule while keeping it in sync.
> >
> I'm reluctant to keep it in the GHC tree; it really is a separate
> project with separate maintainership, dependencies, and contributors.
> 
> That being said, I do agree that the status quo is pretty poor. I was
> going to suggest managing it with git-subtree instead, but I'm not sure
> this would be much of an improvement.
> 
> Cheers,
> 
>  - Ben
> ___
> 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

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

Re: Haddock tree spongled

[Ben Gamari]

"Boespflug, Mathieu"  writes:

> If the status quo is poor, then why not merge the two? git-subtree won't
> fix the problem and will arguably be even harder to manage than submodules.
>
The status quo is indeed awkward at times. However, merging Haddock into
GHC would only serve to shuffle this awkwardness to be felt by a
different group of people.

Currently the awkward workflow is contributing a GHC patch that affects
the subset of GHC's AST that Haddock cares about. This is unfortunate
but not unexpected; working with coupled systems always brings
challenges. However, this is not the common case.

If we were to merge Haddock into GHC then we make harder the lives of
those who work on Haddock independently from GHC. All Haddock changes
would need to go through the GHC tree, we would need to setup special CI
rules to run only the haddock testsuite, and the histories of the two
orthogonal projects would be awkwardly coupled. Given that most of the
commits in the haddock repository are independent from GHC this seems
like a poor trade-off.

As a general rule I think we would be better off trying to loosen GHC's
coupling to other projects than further entrench them.

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

Re: Haddock tree spongled

[Boespflug, Mathieu]

If the status quo is poor, then why not merge the two? git-subtree won't
fix the problem and will arguably be even harder to manage than submodules.

Best,

On Wed, 6 Mar 2019 at 15:59, Ben Gamari  wrote:

> Sylvain Henry  writes:
>
> > Why don't we just put Haddock into GHC's repository? It was proposed in
> > a previous discussion in February [1] and it would avoid the bad
> > experience of having it as a submodule while keeping it in sync.
> >
> I'm reluctant to keep it in the GHC tree; it really is a separate
> project with separate maintainership, dependencies, and contributors.
>
> That being said, I do agree that the status quo is pretty poor. I was
> going to suggest managing it with git-subtree instead, but I'm not sure
> this would be much of an improvement.
>
> Cheers,
>
>  - Ben
> ___
> 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: Haddock tree spongled

[Ben Gamari]

Sylvain Henry  writes:

> Why don't we just put Haddock into GHC's repository? It was proposed in 
> a previous discussion in February [1] and it would avoid the bad 
> experience of having it as a submodule while keeping it in sync.
>
I'm reluctant to keep it in the GHC tree; it really is a separate
project with separate maintainership, dependencies, and contributors.

That being said, I do agree that the status quo is pretty poor. I was
going to suggest managing it with git-subtree instead, but I'm not sure
this would be much of an improvement.

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

Re: Haddock tree spongled

[Sylvain Henry]

Why don't we just put Haddock into GHC's repository? It was proposed in 
a previous discussion in February [1] and it would avoid the bad 
experience of having it as a submodule while keeping it in sync.


With the following commands we can keep the whole commit history:

In Haddock repo:
> mkdir -p utils/haddock
> git rm .arcconfig .arclint .ghci .gitignore .travis.yml
> git mv -k * utils/haddock
> git commit -a -m "Prepare Haddock merge"

In GHC repo:
> git rm -rf utils/haddock
> git commit -a -m "Prepare Haddock merge"
> git remote add haddock https://gitlab.haskell.org/ghc/haddock
> git fetch haddock
> git merge --allow-unrelated-histories haddock/ghc-8.6 -m "Merge haddock"
> git remote remove haddock

[1] https://mail.haskell.org/pipermail/ghc-devs/2019-February/017120.html

Cheers,
Sylvain

On 06/03/2019 13:08, Ben Gamari wrote:

Ryan Scott  writes:


I do think something is afoot here. The current Haddock submodule commit is
at 07f2ca [1], but the ghc-head branch of Haddock is still at commit 8459c6
[2]. It would be good if someone could update the ghc-head branch
accordingly.


Indeed. Done.

It would be nice if we had a better way to handle this. Ideally Marge or
someone similar would land any relevant haddock patches to ghc-head when
landing a GHC MR.

Cheers,

- Ben


___
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: Haddock tree spongled

[Ben Gamari]

Ryan Scott  writes:

> I do think something is afoot here. The current Haddock submodule commit is
> at 07f2ca [1], but the ghc-head branch of Haddock is still at commit 8459c6
> [2]. It would be good if someone could update the ghc-head branch
> accordingly.
>
Indeed. Done.

It would be nice if we had a better way to handle this. Ideally Marge or
someone similar would land any relevant haddock patches to ghc-head when
landing a GHC MR.

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

Re: Haddock tree spongled

[Ryan Scott]

I do think something is afoot here. The current Haddock submodule commit is
at 07f2ca [1], but the ghc-head branch of Haddock is still at commit 8459c6
[2]. It would be good if someone could update the ghc-head branch
accordingly.

Ryan S.
-
[1]
https://github.com/haskell/haddock/commit/07f2ca98fd4249dc6ebad053bd6aef90c814efe0
[2]
https://github.com/haskell/haddock/commit/8459c600e0f6da3f85abefdefe651bbe3ed3da4a
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Haddock tree spongled

[Simon Peyton Jones via ghc-devs]

Yes I'm pointing to gitlab.

[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = https://gitlab.haskell.org/ghc/ghc.git
pushurl = g...@gitlab.haskell.org:ghc/ghc

I have done
git submodule sync
git submodule init
git submodule update

The latter elicits this odd message.

Simon

|  -Original Message-
|  From: Ömer Sinan Ağacan 
|  Sent: 06 March 2019 10:05
|  To: Simon Peyton Jones 
|  Cc: ghc-devs@haskell.org
|  Subject: Re: Haddock tree spongled
|  
|  I just pulled master and `git submodule update` worked. Have you done `git
|  submodule sync` after updating your remotes to point to Gitlab? I'd try
|  doing that and then `git submodule update --init` again afterwards.
|  
|  Ömer
|  
|  Simon Peyton Jones via ghc-devs , 6 Mar 2019 Çar,
|  12:57 tarihinde şunu yazdı:
|  >
|  > Devs
|  >
|  >
|  >
|  > In a clean, up-to-date master I try to say
|  >
|  > Bash$ git submodule update
|  >
|  > fatal: reference is not a tree:
|  > 07f2ca98fd4249dc6ebad053bd6aef90c814efe0
|  >
|  > Unable to checkout '07f2ca98fd4249dc6ebad053bd6aef90c814efe0' in
|  submodule path 'utils/haddock'
|  >
|  >
|  >
|  > What should I do?
|  >
|  >
|  >
|  > Thanks
|  >
|  >
|  >
|  > Simon
|  >
|  > ___
|  > ghc-devs mailing list
|  > ghc-devs@haskell.org
|  > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.
|  > haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devsdata=02%7C01
|  > %7Csimonpj%40microsoft.com%7Cc8487e1fe20546d89ada08d6a21b4bd8%7C72f988
|  > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636874635457691388sdata=q%2F
|  > Fex6QsoPl9IkBydNUGcWLbf2dlrgbzltMAkTHtA5g%3Dreserved=0
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Haddock tree spongled

[Ömer Sinan Ağacan]

I just pulled master and `git submodule update` worked. Have you done `git
submodule sync` after updating your remotes to point to Gitlab? I'd try doing
that and then `git submodule update --init` again afterwards.

Ömer

Simon Peyton Jones via ghc-devs , 6 Mar 2019
Çar, 12:57 tarihinde şunu yazdı:
>
> Devs
>
>
>
> In a clean, up-to-date master I try to say
>
> Bash$ git submodule update
>
> fatal: reference is not a tree: 07f2ca98fd4249dc6ebad053bd6aef90c814efe0
>
> Unable to checkout '07f2ca98fd4249dc6ebad053bd6aef90c814efe0' in submodule 
> path 'utils/haddock'
>
>
>
> What should I do?
>
>
>
> Thanks
>
>
>
> Simon
>
> ___
> 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

Haddock tree spongled

[Simon Peyton Jones via ghc-devs]

Devs

In a clean, up-to-date master I try to say

Bash$ git submodule update

fatal: reference is not a tree: 07f2ca98fd4249dc6ebad053bd6aef90c814efe0

Unable to checkout '07f2ca98fd4249dc6ebad053bd6aef90c814efe0' in submodule path 
'utils/haddock'

What should I do?

Thanks

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