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 mut
> 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 whe
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'
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 pa
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
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
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 tr
"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 awk
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 pr
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 separa
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 -
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
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/07f2ca9
ubmodule 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` w
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ı:
15 matches
Mail list logo
