No so different. The way I see it is that "I" (meaning with submodules
implemented as I proposed) could pull regularly from "your" repositories
(implemented as you proposed) and work with the result (including
submodules). Could you do the same?
But you do not consider the case where you cannot change the submodule
because you do not own it.
For example, git has the subproject xdiff. If git had been able to work
with subprojects as I envision, and if xdiff had been published as a git
repository (not necessarily subproject enabled), it could have been
pulled in git's subdirectory xdiff as a subproject. There would not have
been a separate branch or even repository for xdiff in the git repository.
All changes to xdiff in git could have been committed to the git
repository only. Independently, they could have been published to
upstream and be put into the xdiff repository by its author. But the
last part is what only the owner of the xdiff repository is able to decide.
(Ok, ok... the example sucks badly because xdiff has been massively
changed for its usage in git so the changes would not be integrated by
upstream. But you can imagine where you use a library essentially as is,
only if you discover bugs you fix them immediately in your repository
and keep those fixes in your version of the library, even on upgrade,
until the bugs have been fixed by upstream.)
There is a difference. I would say: If you commit a change to a file in
one branch, it need not be changed in all branches.
Yes, and that is all you need. If the changes are to be part of a branch
of the submodule, they have to be pulled. That is an independent operation.
Because the submodule must be independent of the supermodule.
I see where you are coming from. You have one project that is divided
into subprojects but the subprojects themselves are not independent.
What I would like to solve is the followng: You have a project X, an
this project is made part of two other projects Y and Z (as a submodule
or subproject or whatever you want to call it). The project X need not,
must not or cannot care that it was made a subproject. But in projects Y
and Z, you must be able to bugfix or extend or modify the code of
projectX, and you must be able to push and pull changes between all
three projects (of course we are only talking about the code part of
project X).
Do you see where your solution makes that impossible, and that with more
changes to the repository layout?
Regards
Stephan
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html