Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We need a new generation of source control

rookout.com

Post reply on HN
Print view View original

81–90 of 90 posts

Re: We need a new generation of source control

#81

Post by namibj »

jsmith45 wrote: post #80
apostacy wrote: post #67

This is such a pain point for me. I would LOVE something between subtrees and submodules. I have explored this many times, and if I had the ability to write something like this, I would. I would love it if I could have a child repo that did not require an external remote and could be bundled and stored within a parent repo, unlike a submodule. But I would also like it if it could be more decoupled from the history un…

Well git can most certainly have multiple separate history trees within one repository that are all technically unreleated. One could even use the existing submodule feature to reference unrelated history in the same repository, but the submodule tooling would want create a seperate .git folder, and duplicate everything, and would want a url to identify the repo, rather than knowing to use the parent repo. It ought t…

Last I used submodules, I recall hitting that issue. You need to push the submodule first or one can't checkout the parent repo's master on another machine.

Re: We need a new generation of source control

#82

Post by tatersolid »

hliyan wrote: post #28
brightball wrote: post #26

Earlier quoted context omitted.

You’re not wrong. Part of it is the willingness of people to reach for a dependency that amounts to a few lines of code to avoid. It would be nice if there was a tool that could help you identify just how much of each dependency you actually depend on so you could trim it.

Is there something that is akin to development-time tree-shaking (as opposed to build time)? i.e. you pull a copy of the specific library functions directly into your source?

This is called “vendoring” your dependencies (taking a snapshot into your SCM), and has been common practice for about 30 years. Long before NPM and other language-specific package managers.

Tools for managing vendor branches or sub-trees abound, but good old svn:external and scripts work for most use cases.

Re: We need a new generation of source control

#83

Post by apostacy »

Rotareti wrote: post #74
apostacy wrote: post #67

This is such a pain point for me. I would LOVE something between subtrees and submodules. I have explored this many times, and if I had the ability to write something like this, I would. I would love it if I could have a child repo that did not require an external remote and could be bundled and stored within a parent repo, unlike a submodule. But I would also like it if it could be more decoupled from the history un…

> My dream is to be able to drop a repo inside another repo and have git just treat it as if it were part of the parent repo. And then to be able to bundle the child repo to the parent and push it. I'm not sure if I understand you right, but I think I made what you describe: https://github.com/feluxe/gitsub It's a simple wrapper around git, that allows nested git repositories, with almost no overhead. I use it for a…

Thank you for sharing that! That's really cool!

I'm just very attracted to the idea of bundling repos together. I frequently use git-annex and datalad, and try to keep binaries and helper scripts in different repositories.

Re: We need a new generation of source control

#84

Post by geezerjay »

joshuamorton wrote: post #30
brightball wrote: post #26

Earlier quoted context omitted.

You’re not wrong. Part of it is the willingness of people to reach for a dependency that amounts to a few lines of code to avoid. It would be nice if there was a tool that could help you identify just how much of each dependency you actually depend on so you could trim it.

These things all exist if you use something like bazel/pants/buck to manage your dependencies. When you can construct a DAG of the entire dependency structure you can see exactly how much you depend on any given thing (and get fun dot-graphs of it!). But that requires being precise with dependency declaration in a way that a lot of people don't want to be.

> But that requires being precise with dependency declaration in a way that a lot of people don't want to be.

Some programming language stacks already fix that problem in a transparent way. Take Microsoft's .NET Core+Nuget stack. Developers can add packages to a project without specifying a version number (implicitly it's the latest release) and dependencies are checked when all dependencies are restored.

IIRC Rust's cargo also follow a similar approach, and so do npm and yarn. So, that's pretty much standard at this point.

Re: We need a new generation of source control

#85

Post by geezerjay »

zaphar wrote: post #60
hliyan wrote: post #19

Are we mistaking a dependency control problem as a revision control problem? In a previous life, before microservices, CI/CD etc. existed, we did just fine with 20-30 CVS repositories, each representing a separate component (a running process) in a very large distributed system. The only difference was that we did not have to marshal a large number of 3rd party dependencies that were constantly undergoing version cha…

Most of the mono-repo advocates aren't talking about dependency management. They are talking about the advantages around continuous integration that a good mono-repo tool can bring. The article actually complains less about mono-repos and more about mono-repos on Git and the associated tooling around Git.

> Most of the mono-repo advocates aren't talking about dependency management.

The article however states dependency managements as the main complain, to the point that it's mentioned immediately after the first point where monorepos are mentioned.

Re: We need a new generation of source control

#86

Post by zaphar »

geezerjay wrote: post #85
zaphar wrote: post #60

Earlier quoted context omitted.

Most of the mono-repo advocates aren't talking about dependency management. They are talking about the advantages around continuous integration that a good mono-repo tool can bring. The article actually complains less about mono-repos and more about mono-repos on Git and the associated tooling around Git.

> Most of the mono-repo advocates aren't talking about dependency management. The article however states dependency managements as the main complain, to the point that it's mentioned immediately after the first point where monorepos are mentioned.

Yeah, I found the article to be more about the deficiencies of Git for things version control isn't meant to solve and less about the problems with mono-repos themselves.

Re: We need a new generation of source control

#87

Post by [deleted] »

weberc2 wrote: post #56
masklinn wrote: post #24

Earlier quoted context omitted.

> which may have beaten any HgHub simply because Git has an actual API Git doesn't though. A bunch of shell scripts calling shell scripts calling a few native binaries is pretty much "use subprocessing". libgit came much later, it wasn't part of the original git. However what git did provide was an open, stable, fairly simple and officially supported physical model with which you could easily interact directly, and p…

It looks like you're right about the history. According to the git repo, libgit's first commit was in October of 2008 while Github was incorporated in early 2008 (according to Wikipedia). Github's popularity was probably due to Git's popularity in the Ruby community which may have been due to the official support of the physical model and simple protocols. That said, an "officially supported physical model" is an API…

[deleted]

Re: We need a new generation of source control

#88

Post by headcanon »

boleary-gl wrote: post #76
headcanon wrote: post #21

Earlier quoted context omitted.

One thing about GitLab tooling is that they have features that apply only on a per-repo basis, for example GitLab CI. Suppose for example we have 2 distinct projects - a backend and frontend, which each have their own testing and deployment strategy. GitLab CI only allows one CI pipeline config per-repository. While we could take care of that with scripting, that can easily get out of hand as we increas the number of…

GitLab Product Manager for CI here Thank you for this feedback - it’s something we’re thinking about a lot too. We’ve made some improvements for monorepos (`changes:` keyword) and for micro-services/multi-repo (`trigger:` and `dependency:` keywords) but we’re not satisfied! We have two open Epics - one for making CI lovable for monorepos ( https://gitlab.com/groups/gitlab-org/-/epics/812 ) and one for making CI lovab…

Thanks for listening! We're all big fans of GitLab overall. Good to know you guys are working on filling the feature gap there.

Re: We need a new generation of source control

#89

Post by brechtm »

apostacy wrote: post #67

This is such a pain point for me. I would LOVE something between subtrees and submodules. I have explored this many times, and if I had the ability to write something like this, I would. I would love it if I could have a child repo that did not require an external remote and could be bundled and stored within a parent repo, unlike a submodule. But I would also like it if it could be more decoupled from the history un…

This sounds pretty much what I described in http://www.mos6581.org/git_subtree_alternative. This solution splits your changes between different branches at the time of commit, instead of afterwards like git-subtree does.

While I do present a proof-of-concept implementation using hooks, a proper implementation would require some changes to the git client, I imagine.

Re: We need a new generation of source control

#90

Post by SilasX »

tyrust wrote: post #14
kadendogthing wrote: post #4

As I've stated in another post on here, what's the point of these articles? It just says everything sucks, but doesn't really dive into why or how we could possibly fix any issues they may directly point out. Also it kind of sounds like the author really doesn't have any idea what GitLab is or does, so maybe he should check it out. But allow me to retort these bald assertions presented in the article: Monorepos are g…

>what's the point of these articles? Content marketing.

Sorry for unrelated comment, but I remembered your post about Lyft here and whether Vanguard VTSAX holds it [1]. They updated the holdings on 3/31 and it now shows a $3.4 million holding of ~44k shares of Lyft Class A.

[1] https://news.ycombinator.com/item?id=19640055

Post reply on HN