BTW. >From my own view, we might need a testing maven project (or a github repo), for ensuring all commons repos can be used together, free of dependency hell, or other internal errors about using different versions of a same dependency. But I admit that will really be a time-costing work, and be really hard. I don't know if we can achieve it by adding the "proper" repo and add a module pom at base folder, and adding some tests... Just, I think it useful.
John Patrick <nhoj.patr...@gmail.com> 于2020年8月31日周一 下午9:51写道： > On Mon, 31 Aug 2020 at 14:16, Gary Gregory <garydgreg...@gmail.com> wrote: > > > > On Mon, Aug 31, 2020 at 9:11 AM Matt Sicker <boa...@gmail.com> wrote: > > > > > Git submodules are pointers to other git commits. Therefore, any > component > > > changes made don’t affect the mono repo until you update said mono > repo to > > > point to the new commit. If you do this to point at the latest release > > > tags, this makes for less updates. Otherwise, you’ll want to figure > out a > > > CI system for automatically updating submodules to the latest master > > > commits as they pass CI. > > > > > > > Can that commit be HEAD? > > Used git submodules loads 2010-2015, and not much since. But from > memory it can't be HEAD it has to be a specific commit hash. > > We had loads of issues when people worked on the sub modules > independently, it was easier when every worked with the parent git > module. But that was early 2010's so it might now allow HEAD or a > named branch say develop or master/main. > > We also had loads of maven warnings because we had a wrapper project > so from the git parent module it saw the submodules as maven modules. > But the git parent module maven pom wasn't the parent pom of the git > submodules maven pom. As parent automatically is > <relativePath>../pom.xml</relativePath> > > Our setup was; > > git-module > -> pom.xml (GAV project:maven-wrapper:1) > -> git-submodule-parent > --> pom.xml (GAV project:parent:1) > -> git-submodule-core > --> pom.xml (GAV project:core:1, parent GAV project:parent:1) So > correct relative path is ../git-submodule-parent/poml.xml > > They had ~35 git submodules, not sure if they are still using submodules. > > So it can be useful if you want to have component based git repo's but > it does add an extra overhead layer of maintenance and everyone needs > to be onboard from experience. > > John > > > > > Gary > > > > > > > > > > On Mon, Aug 31, 2020 at 05:17 sebb <seb...@gmail.com> wrote: > > > > > > > On Sun, 30 Aug 2020 at 15:01, Gary Gregory <garydgreg...@gmail.com> > > > wrote: > > > > > > > > > > > > > > > > > > On Sun, Aug 30, 2020 at 9:47 AM Rob Tompkins <chtom...@gmail.com> > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Aug 30, 2020, at 9:44 AM, sebb <seb...@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > > > Some questions: > > > > > > > > > > > > > > > > > > > > > > - does it affect any existing usage? > > > > > > > > > > > i.e. can people continue to use the individual repos exactly > as > > > > before > > > > > > > > > > > > > > > > > > > > no they can’t > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes they can... this would be a new repo, and changes nothing for > > > current > > > > > > > > > usage. This does not affect existing repos. > > > > > > > > > > > > > > > > What about my other queries? > > > > > > > > > > > > > > > > - changes to commit messages: > > > > > > > > can people commit to components directly from the new repo? > > > > > > > > If so, does that change the commit messages? > > > > > > > > > > > > > > > > - maintenance of the new repo: > > > > > > > > what is involved, and how will the project know when updates are > needed? > > > > > > > > > > > > > > > > > Gary > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - does it affect Git emails in any way? > > > > > > > > > > > e.g. do they have different text? > > > > > > > > > > > > > > > > > > > > same emails > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - will it need much maintenance? > > > > > > > > > > > If so, how do we know when it needs updating? > > > > > > > > > > > > > > > > > > > > more maintainance, have to maintain a git hash at a symlink > pointing > > > > to an > > > > > > > > > > external repository > > > > > > > > > > > > > > > > > > > > -Rob > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, 30 Aug 2020 at 14:26, Gary Gregory < > garydgreg...@gmail.com > > > > > > > > > > > > > > wrote: > > > > > > > > > > >> > > > > > > > > > > >> Yes yes "girl" -> "git" > > > > > > > > > > >> > > > > > > > > > > >> On Sun, Aug 30, 2020, 09:24 Gary Gregory < > garydgreg...@gmail.com> > > > > > > > > > > wrote: > > > > > > > > > > >> > > > > > > > > > > >>> I'm talking about girl's own submodules: > > > > > > > > > > >>> > > > > > > > > > > >>> https://git-scm.com/book/en/v2/Git-Tools-Submodules > > > > > > > > > > >>> > > > > > > > > > > >>> https://git-scm.com/docs/git-submodule > > > > > > > > > > >>> > > > > > > > > > > >>> Gary > > > > > > > > > > >>> > > > > > > > > > > >>> On Sun, Aug 30, 2020, 09:09 Rob Tompkins <chtom...@gmail.com > > > > > > wrote: > > > > > > > > > > >>> > > > > > > > > > > >>>> By git submodules, are you talking about a symlink to > another > > > git > > > > > > > > > > >>>> repository inside one of our repositories? > > > > > > > > > > >>>> > > > > > > > > > > >>>> -Rob > > > > > > > > > > >>>> > > > > > > > > > > >>>>> On Aug 29, 2020, at 6:52 PM, Gary Gregory < > > > > garydgreg...@gmail.com> > > > > > > > > > > >>>> wrote: > > > > > > > > > > >>>>> > > > > > > > > > > >>>>> Hi All, > > > > > > > > > > >>>>> > > > > > > > > > > >>>>> Any thoughts for or against creating a new git repository > which > > > > would > > > > > > > > > > >>>>> contain all 'proper' Commons components as git submodules? > > > > > > > > > > >>>>> > > > > > > > > > > >>>>> The idea is to be able to checkout all of Commons 'proper' > in > > > > one go > > > > > > > > > > in > > > > > > > > > > >>>> one > > > > > > > > > > >>>>> place. > > > > > > > > > > >>>>> > > > > > > > > > > >>>>> Gary > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > > --------------------------------------------------------------------- > > > > > > > > > > >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > > > > > > >>>> For additional commands, e-mail: > dev-h...@commons.apache.org > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > -- > > > Matt Sicker <boa...@gmail.com> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
