In theory, there's a disadvantage here in that it puts more work on the end user to manually set that up, but the advantage is there's a simpler understanding of how everything works together.Ģ.
#CRAZY OLD GIT DEFINITION HOW TO#
You have a master repo with a readme instructing people on how to set it up. Have a bunch of repositories with an understanding of what an expected file structure is, ala. It creates a whole new layer to the way your VCS works the consumer needs to understand.ġ. It creates a new level of abstraction for figuring out how everything is related, and what commands you need to be able to keep things in sync (as opposed to just a normal pull/branch/push flow). I think they're difficult to use, because it breaks my mental model of how I expect a repository to work. Git submodules aren't bad in that they're buggy, they do what the documentation suggests. All the other fiddling and querying-and all the things that make version-control-as-history useful-is local. And the only call-central-command operation I use is “git push”. Sure, we use a centralized repo structure.
Of course the default assumption for any VCS operation-unless it has a name like “send-email”-should be that it operates on your own local copy. I think that this idea that non-distributed VCS is somehow the default-as in the obvious, simple thing to implement-is just backwards. And why should it not be? What’s “git log”, “git blame”, or “git merge” got to do with whether there is one canonical repo or a hierarchy of upstreams? The truly important thing about distributed VCS is that it forces almost all of the operations on the repository to be usable locally.
#CRAZY OLD GIT DEFINITION CODE#
So that’s pretty centralized, right? So why use a distributed VCS? Well, why use a local editor or IDE for code that is ultimately going to end up in the cloud somewhere? Sure, you might want to out of preference, but why should you be forced to? The fact is that wherever the code will end up is besides the point when it comes to how to develop it. All our “pull requests” are really merge requests, mostly to the main branch. But I don’t see why I would want to handicap myself with a truly centralized SCM system. But they are a struggle, and lots of people use monorepos instead (which have their own problems.).Īnything can be made to work. Git submodules aren't "bad" and honestly they're an essential feature of git.
The team I was working on kept having issues with using the wrong submodule commit, not having the same commit / push requirements on submodules, etc.Īll of these can be fixed by tools and smart techniques like putting `git submodule update` in the makefile. Fixing merge conflicts and using git in one repo is already hard enough. Basically every operation I do on the git main I need to also do on the submodule if I modified files in bothĤ. I have to go into the submodule, and either commit / push that as well or revert it.
Git diff returns something even after I commit, because the submodule has a change. I'm pretty sure `git submodule update` doesn't always work with this but maybe only when 3)ģ. Git submodules being out-of-sync because I forgot to pull them specifically. You need `git submodule update` or `git clone -recursive`, I thinkĢ. Git submodules are fine and can be really useful, but they are really hard.
0 kommentar(er)
