On Fri, Aug 11, 2023 at 10:47:46PM -0700, Andy wrote:
> How organize such code:
> - editor component uses syntax highlighting component
> - big file viewer uses the same syntax highlighting component
> - main application uses Editor and big file viewer
>
> We have 'diamond" but submodule can be added to subdirectory.
I would say, we need more information to try to do any educated judgement.
Does each of the four components above can be checked out and worked on
completely separately? I mean, is it possible that Alice can check out syntax
highlighter *as a single separate project* and work on its code - modify it,
run tests etc, - while Bob can do the same thing with big file viewer, and so
on - up to the main application which uses the whole pack of stuff?
Another, related, question to consider is that whether it's possible to
somehow "point" the build system of each component (whatever the term "build"
means - because for instance you might be talking about web-y stuff written in
JS where "building" means minifying and creating a bundle or something like
this) to the location of each other component being used. This question should
be considered not because of Git or submodules or because of the general
approach of handling dependencies: that is, when you have "a diamond"
dependency graph, do you "flatten" it when needed or not. Usually flattening
provides more predictable results. If you're not aware of the term/approach,
flattening merely means that each transitive dependency gets represented only
once when you construct "a tree" (real - as a hierarchy or hierarchies of
files and folders on a filesystem, or virtual - when some of the dependencies
are built separately and get linked in when the "outer" components get built).
In our example, flattening would mean that you'd have an FS structure in the
style of
+- project_root/
|
+- syntax_highlighter/
|
+- editor/
|
+- viewer/
|
+- main_app/
...and then, basically, the main_app has a Makefile which "knows" how to first
build editor and viewer, and each or those "knows" how to build
syntax_highlighter etc.
That way, when someone works on editor or viewer, they just set their FS
structure in basically the same way and make sure the build systems of those
projects know where to find syntax_highlighter and how to make it build.
As you can see, adding Git submodules to this picture is a question of
secondary importance.
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/git-users/20230815174751.5umnr7k3gx4wmnbl%40carbon.
