You could also use submodules (or subtrees, haven't tried them yet).

On Monday, 8 September 2014 at 21:55:47 UTC, Trass3r wrote:
> You could also use submodules (or subtrees, haven't tried them yet).

AFAIK the tags and branches does not work over
submodules/subtrees and you would still have 3 github repos with 3 pull request queues.

> with 3 pull request queues

Good argument for the separation :)

On Monday, 8 September 2014 at 19:51:58 UTC, Dragos Carp wrote:
> Cons:
> - migration effort (documentation, merge scripts)
> - current work-flow adjustments
> - the resulted repo history could be sometimes confusing
> - lost github pull-request history

It would also be a pretty serious change for LDC. We are currently using druntime/Phobos as Git submodules.

David

On Monday, 8 September 2014 at 16:59:55 UTC, Andrei Alexandrescu wrote:
>> Did Andrew leave any kind of notes about the process he ended up with?
>> (If it is on wiki, link may be helpful)
>
> Thanks for your interest. Forwarded the question to Andrew to make sure he doesn't miss it. I take it you're on the cusp of volunteering? :o)
>
> Andrei

I have already mentioned in the mail list that I can't afford such commitment for  the time being but if there are simple instructions will try find time to help tih 2.066.1

I am primarily interested with information about various platform build box access and most up do date version of packaging scripts - git part is simple.

On Monday, 8 September 2014 at 19:51:58 UTC, Dragos Carp wrote:
> I have collected a few pros/cons about merging the repositories:
>
> Pro:
> - simplified release tagging and branching
> - atomic commit of cross-repository changes
> - easier to experiment with cross-repository feature branches
> - single pull request queue offering a better overview about the
> project
> - easier grep, easier build
> - simplified build documentation
>
> Cons:
> - migration effort (documentation, merge scripts)
> - current work-flow adjustments
> - the resulted repo history could be sometimes confusing
> - lost github pull-request history
>
> What do you think about this? Would it be worth the effort?
> Destroy!

ne important (in my opinion) disadvantage misssing: considerably harder PR maintenance (missing automatic categorization and separation between phobos / dmd teams). Being forced to look ar DMD pull requests to do Phobos maintenance will add lot of context overhead for me.

I also don't feel like it will help much for release preparation. Bisection and history investigation - undoubtedly. But for release management building stuff is one of the easier parts.

On 9/8/14, 2:55 PM, Trass3r wrote:
> You could also use submodules (or subtrees, haven't tried them yet).

A git expert told me submodules are fail. Is that true? -- Andrei

On Tuesday, 9 September 2014 at 00:28:38 UTC, Andrei Alexandrescu wrote:
> On 9/8/14, 2:55 PM, Trass3r wrote:
>> You could also use submodules (or subtrees, haven't tried them yet).
>
> A git expert told me submodules are fail. Is that true? -- Andrei

As any powerful feature it can be used to great success or great failure :) However it is probably a bad case for deeply connected projects that needs to be updated in sync like it is with dmd and phobos. Those are more useful as a git-only alternative to dub dependencies in my opinion - static relations that don't change often.

`git subtree` may be a betetr match here but I am not familiar with those. Going to check the docs now.

On Tuesday, 9 September 2014 at 00:51:25 UTC, Dicebot wrote:
> `git subtree` may be a betetr match here but I am not familiar with those. Going to check the docs now.

Yeah those definitely look more interesting - as far as I can see subtree is bound to a branch and not to specific commit hash.

Personally, I've never found the multiple repositories inconvenient. About the only place they are are when simultaneous changes are required to more than one of the parts.  That's INTENDED to be rare since it directly implies a non backwards compatible change.  Those changes tend to hurt people and making it more obvious that it's happening and making the bar a little higher to leap isn't a bad thing.

About the only pro listed below that I can agree with is the atomic commit issue (see above for my feelings on those) and the regression hunt.  There's already tooling to deal with the latter, and it works pretty well.  The rest fall into the "yes, you're right, but the benefit it minimal at best.

The con's are more significant to me.  The permissions issues.  The enforced layers.  The fact that the cost of change isn't small and the benefits from the change are small.

I vote no.

If I had to do it all over again, I'd still split them up.

On 9/8/2014 2:24 PM, Dragos Carp via Digitalmars-d wrote:
> On Monday, 8 September 2014 at 20:56:51 UTC, Vladimir Panteleev
> wrote:
>> On Monday, 8 September 2014 at 19:51:58 UTC, Dragos Carp wrote:
>>> I have collected a few pros/cons about merging the repositories:
>>
>> This topic has been discussed in the past. Some more points that I can
>> think of:
>>
>>> Pro:
>>> - simplified release tagging and branching
>>> - atomic commit of cross-repository changes
>>> - easier to experiment with cross-repository feature branches
>>> - single pull request queue offering a better overview about the
>>> project
>>> - easier grep, easier build
>>> - simplified build documentation
>>
>> - easier to run the entire test suite
>> - much easier "git bisect"
>>
>>> Cons:
>>> - migration effort (documentation, merge scripts)
>>> - current work-flow adjustments
>>> - the resulted repo history could be sometimes confusing
>>> - lost github pull-request history
>>
>> - more difficult to assign ownership/responsibility
>
> The directory structure will still be present. I don't think that
> would be a problem, it works pretty well for bigger projects.
>
>> - forking just one component becomes more difficult
>
> Forking a component is a seldom event, working with all three is
> the rule and we should strive to optimize it.
>
>> - more mixing of free and non-free source code in the same repository
>> (although I heard splitting the DMD repo into two (frontend and
>> backend) repositories was being discussed)