chrschilling

4 ms·

1.
by chrschilling 4y ago
The whole topic of access control is way more work than you might expect: There is already an idea and initial implementation of path based ACLs for Josh. However, even if that concept was perfect and already implemented, it would be kind o
2.
by chrschilling 4y ago
You don't even need to make a skeleton repo first. By passing `-o merge` as extra option on the push to a non existing view, the merging of unrelated histories will be done by the server. See: https://github.com/josh-pr
3.
by chrschilling 5y ago
Your dream came true ;) This is what Josh does: git clone https://example.com/some.repo.git:/foo/bar.git And then everything works normally.
4.
by chrschilling 5y ago
For the CI Josh is only used to determine if a given commit affects a given workspace. This can be done server side using the Josh GraphQL API. Having this understanding about the dependencies of workspaces understood by the vcs server(in t
5.
by chrschilling 5y ago
What you are describing is one of the main use cases at ESR Labs (where Josh was created): For developers it is very convenient to work in a single tree. For reviewers and CI it is useful to look at the changes in a larger context. For cons
6.
by chrschilling 5y ago
On a basic level, yes, both Josh and git filter-branch do essentially the same thing. The difference being that Josh is much faster not just compared to git filter-branch but also compared to all the other similar tools out there, especia
7.
by chrschilling 5y ago
Yes that it exactly the idea. Translating between both mono and poly repo, partial sharing with others (distributed development) and gradual adoption without a big bang.
8.
by chrschilling 5y ago
IATAOJ (I Am The Author Of Josh) ;) You are absolutely right about the main motivation of using a monorepo: Allowing upsrteam library maintainers to see downstream usage of their code and make the required downstream changes themselves at t